LINUX.ORG.RU
решено ФорумAdmin

[backup] xfsdump vs dump


0

1

Я честно прочёл man dump, но так и не понял пары вещей:

  • бэкап, сделанный с ФС в режиме rw будет гарантированно консистентным? xfsdump это обеспечивает, используя xfs_freeze.
  • возможно ли прерывание с последующим возобновлением с этого же места? Tape checkpoint явно не поможет, т.к. смена носителей места не имеет.

Спасибо.

★★★★★

>xfsdump это обеспечивает, используя xfs_freeze

Шо? xfsdump таки вызывает xfs_freeze? Ты гонишь.

Юзай lvm-snapshot и не парься.

anonymous ()
Ответ на: комментарий от anonymous

Насколько я помню, отсутствие вызова xfs_freeze перед фиксацией снапшота может добавить гемора. А из снапшота уже, наверное, можно и дампить, хотя я обычно предпочитаю классические методы, типа rsync. Наверное, потому что я не сторадж-админ :)

nnz ★★★★ ()
Ответ на: комментарий от anonymous

xfsdump таки вызывает xfs_freeze? Ты гонишь.

Странно, мне казалось, что я это видел в руководстве. Оказалось, нет.

Юзай lvm-snapshot и не парься.

Я об этом думаю, но, кажется, там не слишком реализуемо инкрементальное резервное копирование.

GotF ★★★★★ ()
Ответ на: комментарий от nnz

...я обычно предпочитаю классические методы, типа rsync. Наверное, потому что я не сторадж-админ :)

Да мне вообще для домашнего пользования... Просто заинтересовали средства, которые «ближе» к ФС. Например, такая фича как атрибут «no dump». Сейчас пользуюсь rsync, но исключения делать не всегда удобно. Ну и крутится мысль об использовании инкрементальных методов.

GotF ★★★★★ ()
Ответ на: комментарий от GotF

>Я об этом думаю, но, кажется, там не слишком реализуемо инкрементальное резервное копирование.

Насколько я понимаю, lvm-снапшоты и xfsdump не исключают друг друга. По сути, снапшот lvm просто фиксирует состояние ФС (или любых других данных на lv) на время бэкапа. После снятия бэкапа снапшот обычно удаляют, так как он занимает место и вызывает тормоза.

nnz ★★★★ ()
Ответ на: комментарий от nnz

А, понятно. В общем, я так понял, лучше и дальше обходиться rsync ± какие-то костыли типа rdiff-backup (фраза «The idea is to combine the best features of a mirror and an incremental backup.» в описании выглядит привлекательно, надо попробовать), и не морочить себе голову примочками для «ынтырпрайза»...

GotF ★★★★★ ()

Итого:

— с заморозкой я ступил, никакого волшебства тут нет нахаляву.

— возможность прерывания, по-хорошему, не слишком-то нужна.

Отписавшимся спасибо.

GotF ★★★★★ ()
Ответ на: комментарий от nnz

Не забывать, что для снапшота на LVM нужно дополнительное место, сопоставимое с размером данных, иначе ага.

iZEN ★★★★★ ()
Ответ на: комментарий от iZEN

Не забывать, что для снапшота на LVM нужно дополнительное место, сопоставимое с размером данных, иначе ага.

А где-то есть волшебные снапшоты, которые место не жрут?

GotF ★★★★★ ()
Ответ на: комментарий от iZEN

>Не забывать, что для снапшота на LVM нужно дополнительное место, сопоставимое с размером данных, иначе ага.

Сопоставимое с размером изменений в vg на время жизни снапшота, ага.

Учите матчасть.

anonymous ()
Ответ на: комментарий от anonymous

Таки оно гарантирует консистентность

http://en.wikipedia.org/wiki/Xfs#Native_backup.2Frestore_utilities

The xfsdump utility backs up an XFS filesystem in inode order, and in contrast to traditional UNIX file systems which must be unmounted before dumping to guarantee a consistent dump image, XFS file systems can be dumped while the file system is in use. This is not the same as a snapshot since files are not frozen during the dump.

Хоть это и не снапшот.

GotF ★★★★★ ()
Ответ на: комментарий от anonymous

Сопоставимое с размером изменений в vg на время жизни снапшота, ага.

Нет. Я имел в виду дополнительное место для метаданных снапшота.

iZEN ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.