Ну, если найдёте, да, напишите пожалуйста либо мне на почту menkovich@gmail.com, либо на нашу контактную contact@chtoes.li (http://chtoes.li/help/ вот тут она есть, в разделе «Как нам помочь»)
Ну это работа DNS или схожего по функционалу с DNS сервиса (не помню как виндовый аналог называется). Вы в любом случае подключаетесь в локальную сеть и что возможно в ней — возможно и в VPN.
Почти ничего(кроме редких ситуаций, когда чтобы бэкпортировать пакет нужно ввести больше 4-5 команд) не мешает нужные пакеты собирать аналогично с source-based
Индекс для того и существует, чтобы делать вытаскивание файлов моментальным. Открыл файл, прочитал индекс, узнал смещение, перешёл по нему, прочитал файл, закрыл файл.
Для полного бэкапа, равно как и для инкремента происходит подсчёт контрольных сумм, единственное что при полном бэкапе не происходит — сравнение двух деревьев с контрольными суммами.
Спасибо, я правильно понимаю, что shadow copy это в некотором смысле реализация версионности у Microsoft и система при этом сохраняет предыдущую версию файла? Тогда ничего удивительного что вы получили такой прирост по скорости: исчезли лишние io операции и вероятно ещё какая-то вычислительная нагрузка. Плюс я не уверен, что тест был честный, поскольку при первом прогоне файлы могли быть загружены в оперативную память операционной системы и последующий доступ к ним будет в разы быстрее.
После окончания второй недели идёт неделя декремента: d- d- d- d- d- d- f и после снова инкременты. Худший исход для такой схемы — потеря полного бэкапа
1. Декрементальный это тоже самое что инкрементальный (то есть сохранающий икремент), только в обратную сторону. То есть из прошлого полного и текущего состояния вычисляется что изменилось по сравнению с текущим и сохраняется полный бэкап, а в прошлом остаются только изменения относительно текущего состояния.
2. Тем, что если у вас будет один полный и тринадцать инкрементов, то битый, например, первый инкрементальный оставит вас без бэкапов за две недели. А так только за неделю.
Вообще можно ещё в архив добавлять избыточность (dar умеет работать с par2), чтобы можно было восстанавливать даже битые архивы.
Запись это тоже операция ввода вывода, а сжатие на современных процессорах (например gzip 3..5) выполняется с очень слабой задержкой по времени. Равно как и вычисление контрольных сумм.
Не нужно указывать filename.1.dar, нужно указывать просто filename, см «Я думаю, все уже заметили, что название архива никак не упоминает расширение файла .dar. А ещё в имени файла откуда-то взялась цифра 1. Это всё потому, что dar изначально предназначается для бэкапа на сменные носители (CD, DVD или, например, ленточные накопители), поэтому он архивирует в слайсы, а циферка 1 возникает потому, что этот слайс первый.»
Ещё можно указывать -O --no-warn ключи, чтобы скипать сообщения.
"-J same as -K but the given key is used to decrypt the archive of reference" — тут ключевое слово «для расшифровки»
То есть в full мы зашифровываем данные, а потом когда делаем diff — указываем -J потому что нам нужно зашифрованные данные расшифровать.
А вот это сообщение "-J is only useful with -A option, for the archive of reference" это скорее баг, да. То есть сообщение просто не должно показываться. Я бы отправил багрепорт.
Там ещё внутри есть OpenVPN сервер, который вполне себе работает. Хоть и не без проблем :)
Спасибо, я правильно понимаю, что shadow copy это в некотором смысле реализация версионности у Microsoft и система при этом сохраняет предыдущую версию файла? Тогда ничего удивительного что вы получили такой прирост по скорости: исчезли лишние io операции и вероятно ещё какая-то вычислительная нагрузка. Плюс я не уверен, что тест был честный, поскольку при первом прогоне файлы могли быть загружены в оперативную память операционной системы и последующий доступ к ним будет в разы быстрее.
Декреметальных хорош, когда часто нужен только последний, и чтобы не восстанавливать полседовательно серию бэкапов можно восстановить только один.
После окончания второй недели идёт неделя декремента: d- d- d- d- d- d- f и после снова инкременты. Худший исход для такой схемы — потеря полного бэкапа
2. Тем, что если у вас будет один полный и тринадцать инкрементов, то битый, например, первый инкрементальный оставит вас без бэкапов за две недели. А так только за неделю.
Вообще можно ещё в архив добавлять избыточность (dar умеет работать с par2), чтобы можно было восстанавливать даже битые архивы.
Ещё можно указывать -O --no-warn ключи, чтобы скипать сообщения.
"-J same as -K but the given key is used to decrypt the archive of reference" — тут ключевое слово «для расшифровки»
То есть в full мы зашифровываем данные, а потом когда делаем diff — указываем -J потому что нам нужно зашифрованные данные расшифровать.
А вот это сообщение "-J is only useful with -A option, for the archive of reference" это скорее баг, да. То есть сообщение просто не должно показываться. Я бы отправил багрепорт.