Re: Вопросы про бэкапы.
03.06.2012 23:18, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Sun, 03 Jun 2012 22:26:12 +0400:
>
> АН> У dar есть серьёзный минус: для создания декрементального бэкапа
> АН> требуется сделать ещё один полный.
>
> А, то есть он не умеет делать декрементальный бэкап, а только делает
> вид? Понятно, спасибо за исследование, значит, я не зря после первого
> косого взгляда на него забил, можно не смотреть в его сторону.
Я бы так не сказал. Он их делает. Но для этого требуется второй полный бэкап.
С bsdiff я вчера погорячился. Это возможно сделать dar.
Т.е.:
1. Делается полный бэкап (всего один раз).
2. Делается дневной инкрементальный. dar -c day_diff -A full0.
3. cp full0 full1.
4. Слияние: dar -+ full0 -A day_diff.
5. Делается штатный декрементальный бэкап и удаляется старый.
dar -+ full1 -A full0 -@ full1 -ad && rm full0
Вот выдержка из usage notes:
"Another point is that you cannot shrink a given file: many (all?) operating
systems provide hook to create/append/overwrite data to an existing file but not
to remove data from it and get a smaller file as result. This operation when
needed is usually emulated by the applications, creating a temporary file in
which is added the part to retain from the original file, then once the copy is
finished, the original file is deleted an the temporary file is renamed at the
place of the original one. Thus here the process to transforming a full backup
into a decremental backup will not simply remove data from the filesystem, but
will copy (thus add) a portion of the data to a new file and then remove the old
data. Thus whatever the method used to do a decremental backup, you will end at
a time with two full archives, and will require disk space to store both of them.
Seen this, the dar implementation is to let the user do a normal full backup at
each step [Doing just a differential backup sounds better at first, but this
would end in more archive manipulation, as we would have to generate both
decremental and new full backup, and we would manipulate at least the same
amount of data]. Then with the two full backups the user would have to use
archive merging to create the decremental backup (using -ad option). Last, once
the resulting (decremental) archive have been tested and that the user is sure
this decremental backup is viable, he can remove the older full backup and store
the new decremental backup beside older ones and the new full backup. This at
last only, will save you disk space and let you easily recover you system using
the latest (full) backup."
http://dar.linux.free.fr/doc/usage_notes.html#Decremental_Backup
> АН> Вопросы следующие:
> АН> 1. Использует ли rdiff-backup (не dar), при создании дифа,
> АН> промежуточный образ или её бэкап может находиться в противоречивом
> АН> состоянии (например, половина файлов скопировалось в архив, но
> АН> выключилось питание)?
> За rdiff-backup не скажу, но подозреваю, что результирующий бэкап будет
> в непротиворечивом состоянии "что успело, то скопировалось, остальное
> старое". У него же последний бэкап - файловая система как она есть, и я
> думаю, что он диффы делает пофайлово.
Это противоречивое состояние. Некорректно будут сохранены синхронно обновляемые
файлы.
Пример: вы добавили нового пользователя.
Пользователь был внесён в passwd ив shadow.
Passwd был скопирован, затем исчезло питание.
> Скажу за модель rsnapshot - у него точно состояние будет
> непротиворечивое вышеописанное. Ну, тамб возможно, что rsync сначала
> удалит удаленные на том конце файлы, а потом скопирует новые, что может
> привести к отсутствию файла в последнем бэкапе при переименовании, но,
> во-первых, он при этом есть в предыдущем бэкапе, а во-вторых, rsync'у
> можно сказать "удалять после".
> Единственное место, которое может нарваться на слет питания - это cp -al
> daily.0 daily.1. При этом в daily.1 будет неполная копия. Но в этом
> случае rsync не успеет запуститься, и в daily.0 будет полная, но старая
> копия - как если бы питание слетело до запуска бэкапа вообще.
Понятно.
Может и rdiff-backup... Почитаю ещё про dar. И, всё-таки rdiff-backup или
rsnapshot (там вообще всегда возможно откатиться).
Reply to: