Dump и Restore, резервное копирование данных

Трудно переоценить роль резервного копирования на сервере, когда речь идет о целостности и сохранности данных. Информация может быть утеряна разными способами и по разным причинам, удалена или испорчена случайно, сервер может быть взломан и информация уничтожена злонамеренно, в конце концов жесткие диски могут и умирать. Встроенные во FreeBSD, системные утилиты Dump и Restore, являются одним из самых надежных и безопасных средств резервного копирования в Unix системах, это неотъемлемый инструмент любого системного администратора, призванный, если и не восстановить данные в полном объеме, то хотя-бы вернуть то, что было сохранено и смягчить возможные последствия от потери информации.

Команда dump, работает с блочными устройствами и деревом inode, умеет создавать, как полную резервную копию данных, так и инкрементные дампы, до 10 уровней, целого диска или любого, отдельно взятого раздела. Dump работает, даже если файловая система, бэкап которой вам необходимо сделать, в данный момент является "живой", то есть, смонтирована и используется ( как правило, так и есть ), перед копирование делается снимок ( snapshot ) файловой системы, что-бы убедится, что в процессе работы утилиты, не было сделано никаких изменений. Кроме того, команда dump умеет сжимать данные. Dump умеет разделять резервную копию на куски указанной длины или по мере заполнения принимающего устройства.

По-умолчанию, если не было явно назначено место хранения резервной копии, dump создает ее в устройстве для хранения на магнитной ленте.

Типичный процесс создания резервной копии данных, может выглядеть следующим образом:

/# dump -0auL -f /root/backup.dump /dev/da0s1d
  DUMP: Date of this level 0 dump: Mon Jun 15 16:02:55 2009
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping snapshot of /dev/da0s1d (/var) to /root/backup.dump
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 129172 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 129140 tape blocks on 1 volume
  DUMP: finished in 23 seconds, throughput 5614 KBytes/sec
  DUMP: level 0 dump on Mon Jun 15 16:02:55 2009
  DUMP: Closing /root/backup.dump
  DUMP: DUMP IS DONE

В данном примере, с помощью команды dump, делается полная резервная копия ( флаг -0 ), файла устройства /dev/da0s1d, смонтированного в /var, в файл /root/backup.dump. Флаг -L сигнализирует, что раздел, подлежащий резервному копированию, находится на живой файловой системе и перед началом нужно сделать снимок данного раздела и уже затем приступать к операции.

Если флаг -L установлен, dump создает снимок в директории .snap, корневого раздела файловой системы. Файл снимка будет удален, как только dump завершит работу.

Всегда используйте данную опцию на живой файловой системе. Если dump с опцией -L применяется к разделу, находящемуся в режиме "только чтение" ( read only ), или к не смонтированному разделу, опция -L будет проигнорирована.

Опция , означает "auto-size", то есть будет заполнено все cвободное место на носителе

Опция -u, указывает сохранить ( обновить ) служебную информацию в файл /etc/dumpdates, она будет использована при следующих бэкапах:

/# cat /etc/dumpdates
/dev/da0s1d                      0 Mon Jun 15 16:02:55 2009

Для создания инкрементного архива, вам нужно указать в опциях команды, уровень дампа от 1 до 9 ( 0 - полный архив ), при этом, dump будет использовать данные о времени последнего резервного копирования из файла /etc/dumpdates.

Выглядит это следующим образом:

/# dump -1auL -f /usr/backup.dump1 /dev/da0s1d
  DUMP: Date of this level 1 dump: Mon Jun 15 16:10:08 2009
  DUMP: Date of last level 0 dump: Mon Jun 15 16:02:55 2009
  DUMP: Dumping snapshot of /dev/da0s1d (/var) to /usr/backup.dump1
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 153 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 137 tape blocks on 1 volume
  DUMP: finished in less than a second
  DUMP: level 1 dump on Mon Jun 15 16:10:08 2009
  DUMP: Closing /usr/backup.dump1
  DUMP: DUMP IS DONE

В результате, также будет обновлена информация в файл /etc/dumpdates:

/# cat /etc/dumpdates
/dev/da0s1d                      0 Mon Jun 15 16:02:55 2009
/dev/da0s1d                      1 Mon Jun 15 16:10:08 2009

Создав резервную копию файловой системы, желательно переместить файл дампа в более безопасное место, например на, специально предназначенный для этого, сервер бэкапов, что-бы избежать потери уже сохраненных данных в случае аппаратного сбоя, или можно сразу создать резервную копию с сохранением на удаленный сервер, через безопасное SSH соединение. Делается это следующим образом:

vds-admin /# dump -0auL -f - /dev/da0s1d | bzip2 | ssh backup@192.168.50.50 -p 22 dd of=/root/vds-admin.dump

В результате будет создана полная резервная копия ( -0 ) устройства da0s1d и отправлена на удаленный сервер backup_server с именем пользователя backup. Для сжатия будет использован bzip2 ( архиватор можно использовать, какой вам больше нравится, gzip, compress ), что-бы уменьшить трафик, далее команда dd примет входной поток и отправит его в файл /root/vds-admin.dump.

Полный вывод проделанной операции, выглядит так:

vds-admin /# dump -0auL -f - /dev/da0s1d | bzip2 | ssh backup@192.168.50.50 -p 22 dd of=/backup/vds-admin.dump
  DUMP: Date of this level 0 dump: Mon Jun 15 17:03:39 2009
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping snapshot of /dev/da0s1d (/var) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 129173 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 129141 tape blocks
  DUMP: finished in 33 seconds, throughput 3913 KBytes/sec
  DUMP: level 0 dump on Mon Jun 15 17:03:39 2009
  DUMP: DUMP IS DONE
126240+1 records in
126240+1 records out
64635271 bytes transferred in 22.252234 secs (2904664 bytes/sec)
При использовании архиватора compress, значительно снижается нагрузка на сеть, но ценой повышенной нагрузки на процессор.

Команда restore, выполняет восстановление данных, из сохраненных ранее, программой dump, резервных копий. Например можно восстановить из резервной копии данных, удаленный по неосторожности, файл. Как и dump, Restore можно использовать для восстановления файлов по сети.

Обычный сценарий для команды restore, восстановление из резервной копии на пустой раздел, отформатированный с помощью утилиты newfs. Сначала восстанавливается полная резервная копия, после чего можно восстанавливать инкрементные архивы, в порядке их создания.
Вышеописанная процедура выглядит примерно следующим образом:

# newfs /dev/da0s1a
# mount /dev/da0s1a /mnt
# cd /mnt
# restore -r -f /usr/dumpfile

В данном примере, команда restore восстановит резервную копию данных /usr/dumpfile, в текущую директорию, перейти в нужную директорию можно с помощью команды cd.

Еще одна замечательная особенность команды restore, это возможность работы в интерактивном режиме, то есть вы можете просматривать содержимое резервной копии данных, листать файлы и директории, помечать необходимое для восстановления. Эта возможность просто незаменима при восстановлении файлов, удаленных по ошибке.

В интерактивной оболочке восстановления, присутствует достаточно команд, обеспечивающих вполне комфортную навигацию по содержимому дампа и выбора нужных файлов для восстановления. Команды ls, cd, pwd, являются эквивалентами команд из обычной оболочки и используются для навигации по резервной копии данных. Используя команды add и delete, можно выделять файлы и директории для последующего восстановления. После того как необходимые данные выделены, можно использовать команду extract, для их восстановления.
Выглядит этот процесс примерно следующим образом:

# restore -i -f /usr/dump1
restore > ls
.:
.cshrc     bin/     dev/     home@    mnt/     sbin/    var/
.profile   boot/    dist/    lib/     proc/    sys@
.snap/     cdrom/   entropy  libexec/ rescue/  tmp/
COPYRIGHT  compat@  etc/     media/   root/    usr/
restore > add sbin
restore > add rescue
restore > extract
restore > quit

Также при использовании интерактивного режима команды restore, для восстановления резервной копии данных из дампа, можно воспользоваться командой what

restore > what
Dump   date: Sat Apr 14 16:40:03 2007
Dumped from: the epoch
Level 0 dump of / on server.example.com:/dev/ad0s1a
Label: none

Вот собственно и все. Не забудьте полистать соответствующие страницы man руководства, там все довольно подробно расписано.
Удачных бэкапов.

Комментарии

Огромное спасибо автору!
Все отлично прокомментировано, доступно и что самое важное - мне это очень пригодилось.
P.S. Про ключик -a забыли рассказать,
"# dump -0auL..."
но думаю труда не составит и самому посмотреть =)

спасибо, упомянул на всякий случай)

# newfs /dev/da0s1a
# mount /dev/da0s1a /mnt
# cd /mnt
# restore -r -f /usr/dumpfile

За это спасибо.Ибо тупил неимоверно.

Капча прикольная

Тема не раскрыта до конца. Твёрдая тройка автору (и то, только по тому, что какие-то маны читал)
"dump создает снимок в директории .snap, корневого раздела файловой системы."
почему "корневого раздела" ? Что других не существует ?
"создать резервную копию с сохранением на удаленный сервер, через безопасное SSH соединение. Делается это следующим образом: ........ -p 22 dd of=/root/vds-admin.dump" и получим по кривым ручкам :) /root скорее всего имеет привилегии 755
Восстановление после бацкапа с помощью bzip2 вааще не описано !

все что перечислено комментатором, не более чем опечатки и неточности, я не писатель, будет время, поправлю
"dump создает снимок в директории .snap, корневого раздела файловой системы."
он создает его, В КОРНЕ КОПИРУЕМОЙ ФАЙЛОВОЙ СИСТЕМЫ, в папке .snap, если папки нет, -L выплюнет ворнинг
SSH аналогично, ежу понятно что backup нихрена не пихнет в папку рута, изначально было просто 192.168.50.50, юзера потом дописал, не учтя папку назначения

man bzip2

может еще грамматические ошибки наковыряли ?

Вопрос следующий.
С дамп - рестором научился работать, но на практике возникла проблема.
Если восстановить дампы на совершенно другой сервер - появляется проблема с сетью. На сервере крутятся сервисы такие как BGP, прокси, фаервол, впн и т.д., которые требовательны как раз к названию интерфейсов...
Просто переименовать интерфейс в rc.conf результата не дало.
Сталкивался ли кто-то и как лучше поступить при восстановлении?

Тоже развернул у себя на сервере инкрементное резервное копирование. http://plutov.by/post/incremental_backup

у меня вот так: http://plutov.by/post/incremental_backup

класс,чувак!

Может изврат, но у меня вот так было:
LiveCD -> Shell на целевом компе

# bsdinstall partedit
# mount -t ufs -o rw /mnt /dev/da0p2
# rm -d /mnt/.snap   (чтоб не ругалось при ресторе)
# ssh-keyscan -t dsa host.ip.where.dump > /tmp/known-hosts   (dump лежал на другой фре)
# cd /mnt
# ssh -c blowfish -o UserKnowHostsFile=/tmp/known-hosts -o HashKnowHosts=yes -c blowfish \
root@host.ip.where.dump dd if=/backups/server.dmp | restore -rf -

Без ssh-keyscan постоянно выводит запрос на повтор пароля.

Спасибо помогло! Очень очень!!!!

Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
Регистр имеет значение
 oooo   oooooo   oooo                    ooooooooo.     oooooooooooo        .o   
`888 `888. .8' `888 `Y88. d'""""""d888' .d88
888 `888. .8' oooo oooo ooo 888 .d88' .888P .d'888
888 `888.8' `88. `88. .8' 888ooo88P' d888' .d' 888
888 `888' `88..]88..8' 888`88b. .888P 88ooo888oo
888 888 `888'`888' 888 `88b. d888' .P 888
o888o o888o `8' `8' o888o o888o .8888888888P o888o


Введите код, изображенный в стиле ASCII-арт.