Бэкап/перенос FreeBSD (dump/restore)

Комментарии ()

Говорят, что системные администраторы делятся на тех, кто делает бэкапы, и тех, кто уже делает бэкапы. Ранее я чего то там бэкапил на фтп по ночам. Но недавно, после длительной инсталяции Directadmin'а и допиливания хостинг-сервера под свои нужды, по непонятым причинам побились системные файлы, в часноcти /etc/master.passwd. В общем зайти с консоли я уже не мог, да и жалко было потраченого времени. Вопрос бэкапа был отложен в длинный ящик, так как всегда находились якобы более важные дела. 

Для себя поставил задачу сделать бэкап(snapshot) системы в целом, дабы в день X развернуть ее за несколько минут. А вот бэкапы конфигов и нужных даных - как и ранее переодически хранить на отдельном сервере.

Далее опишу свою методику создания и розволрачивания бэкапа FreeBSD.

На отдельном сервере(192.168.1.1) поднимаю NFS-сервер. На сервере, который нужно забекапить

# df -h
Filesystem      Size    Used   Avail Capacity  Mounted on
/dev/ada0s1a    991M    813M     98M    89%    /
devfs           1.0k    1.0k      0B   100%    /dev
/dev/ada0s1e    991M     28k    912M     0%    /tmp
/dev/ada0s1f    886G    5.8G    810G     1%    /usr
/dev/ada0s1d    9.7G    348M    8.6G     4%    /var
procfs          4.0k    4.0k      0B   100%    /proc

монтирую NFS-шару в /mnt/backup, куда буду складывать архив бэкапа (настройка NFS-клиента описана тут)

mount_nfs 192.168.1.1:/mnt/backup /mnt/backup

Смотрим, что получилось

# df -h
Filesystem                 Size    Used   Avail Capacity  Mounted on
/dev/ada0s1a               991M    813M     98M    89%    /
devfs                      1.0k    1.0k      0B   100%    /dev
/dev/ada0s1e               991M     28k    912M     0%    /tmp
/dev/ada0s1f               886G    5.8G    810G     1%    /usr
/dev/ada0s1d               9.7G    348M    8.6G     4%    /var
procfs                     4.0k    4.0k      0B   100%    /proc
192.168.1.1:/mnt/backup    1.8T    2.1G    1.6T     0%    /mnt/backup

Создание бэкапа в файл

Поначалу, я вооружился man'ом по комманде dump, и смело выполнял бэкап в файл следующим способом:

dump -0 -auLf - / | gzip -q > /backups/root.dump.gz
dump -0 -auLf - /usr | gzip -q > /backups/usr.dump.gz
dump -0 -auLf - /var | gzip -q > /backups/var.dump.gz

Применяемые опции:
-L – дамп снимается с «живой» файловой системы, т.е. она смонтирована в режиме запись/чтение (при ее использовании создается снимок в директории .snap, корневого раздела, который будет удален по завершению работы dump);
-f – писать в файл (по умолчанию вывод направлен на стример).

НО ЭТО НЕ РАБОТАЕТ!

Бэкап создается, но при попытке развернуть его, получил ошибку вида:

unknown tape header type 16777216
abort[yn]n
Checksum error 65411300137, inode 0 file 
resync restore, skipped 69168 blocks
expected next file 70660, got 0
...
partial block read: 20253 should be 32764
End-of-tape encpuntered
Mount tape volume 2
Enter "none" if there are no more tapes
otherwise enter tape name (default: /mnt/backup/var.dump.gz2)
...
ругань на cannot create hard link
...
bad entry: incomplete operation
name: /sbin/adjkerntz
parent name ./sbin
sibling name: ./sbin/zpool
entry type: LEAF
inode number: 70660
flags: NEW
abort?[yn]

Данную проблему можно обойти если делать snapshot самому, а затем дампить с него. Делаем snapshot корня в файл /.snap/2014010700

mount -u -o snapshot /.snap/2014010700 /

Привязываем созданный снапшот к устройству /dev/md1 (номер зависит от праметра -u)

mdconfig -a -t vnode -f /.snap/2014010700 -u 1

Делаем простой дамп

dump -0 -a -f root_ad4s1a.img /dev/md1

Если нужен запакованный дамп

dump -0 -a -f - /dev/md1 | gzip -9 > root_ad4s1a.img.gz 

Если нужен запакованный дамп со сбросом на ftp

dump -0 -a -f - /dev/md1 | gzip -9  - | ftp -u ftp://login:password@host/root.dump.gz - 

Т.е. получается, что делается дамп со снапшота, затем переадется через пайп (|) на архивацию gzip, после чего отправляем по ftp. Синтаксис отправки по ftp [протокол]://[логин]:[пароль]@[сервер]/[путь/][файл_дампа].

Отключаем снапшот

mdconfig -d -u 1

При этом, мы не блокировали никаких операций на HDD, не перемонтировали в RO и получили рабочий дамп, в чем сейчас и убедимся.

Написал небольшой php-скрипт, который автоматизирует процес бекапа

Перенос системы с винта на винт

Если нужно не бэкапить, а перенести с hdd на другой hdd, то:

1) Создаем временные каталоги для монтирования нового hdd

mkdir /tmp/root /tmp/var /tmp/usr

Монтируем слайсы нового hdd

mount /dev/ad4s1a /tmp/root
mount /dev/ad4s1e /tmp/var
mount /dev/ad4s1d /tmp/usr

Выполняем dump для каждого старого раздела, направив вывод в соответствующий новый, следующим образом:

( dump -0Lf - / ) | ( cd /tmp/root ; restore -rf - )
( dump -0Lf - /var ) | ( cd /tmp/var ; restore -rf - )
( dump -0Lf - /usr ) | ( cd /tmp/usr ; restore -rf - )

 Также следует отметить, что дамп живой системы (параметр L) невозможен при включенном журналировании. Если при выполнении дампа у вас возникла ошибка

mksnap_ffs: Cannot create snapshot //.snap/dump_snapshot: /: Snapshots are not yet supported when running with journaled soft updates: Operation not supported dump: Cannot create //.snap/dump_snapshot: No such file or directory

то необходимо загрузиться в Single Mode и выполнить отключение journaled soft-updates

tunefs -J disable /dev/adaxxx
tunefs -n disable /dev/adaxxx
tunefs -j disable /dev/adaxxx

Восстановление из дампа

Восстановление происходит при помощи утилиты restore.
Основные ключи:

  • -i восстановление в интерактивном режиме
  • -f file восстановление из файла
  • -r Восстановление (создание заново файловой системы). Целевая файловая система, должна быть сделана ранее с newfs(8), смотнтирована, и пользователь должен перейти в подготовленную ранее файловую систему прежде чем начнется восстановление нулевого уровня из резервной копии. Если уровень 0 восстановлен удачно, флаг -r может использоватся для восстановления всех необходимых инкрементальных бекапов выше уровня 0. Флаг -r устраняет интерактивное извлечение файлов и может являтся вредным , если он не будет применятся аккуратно.Более подробно описаны ключи man restore (RU)
  • -v заставляет выводить имя каждого файла (обычно restore работает тихо)
  • -y При ошибках и бедблоках игнорирует их и продолжает восстановление
  • -N фейковое восстановление, т.е. читается дамп и имитируется восстановление, без реального извлечения файлов. Полезно для тестирования дампа.
  • -x извлечение всех файлов

Выборочное восстановление файлов из дампа (без сжатия)

# restore -if root_ad4s1a.img
restore > ls
.:
.cshrc                 dev/                   new/
.profile               dist/                  proc/
.snap/                 entropy                rescue/
etc/                   root/
COPYRIGHT              home@                  sbin/
bin/                   lib/                   sys@
boot/                  libexec/               tmp/
cdrom/                 media/                 usr/
compat@                mnt/                   var/

restore > cd /etc
restore > add rc.conf
restore > add /boot/*
restore > extract
You have not read any tapes yet.
If you are extracting just a few files, start with the last volume
and work towards the first; restore can quickly skip tapes that
have no further files to extract. Otherwise, begin with volume 1.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
restore > q

В результате в текущей папке будет восстановлены /boot/* и /etc/rc.conf со всеми правами, которые были ранее.

Можно также восстанавлить и в автоматическом режиме.
Предварительно переходим в нужную папку и делаем

restore -xf root_ad4s1a.img

Если дамп был сжат, то можно его восстановить например в папку /usr/restore следующим образом:

gzip -d  root_ad4s1a.img.gz  | ( cd /usr/restore ; restore -xf - )

Полного восстановления раздела из дампа:
Для начала нужно подготовить раздел жесткого диска Форматируем его (Указать свой!!!)

newfs /dev/ad0s1a

Монтируем и идём туда:

mount /dev/ad0s1a /mnt/ad0s1a.ufs
cd /mnt/ad0s1a.ufs

Восстановление дампа

restore -rf /путь/к_фалу/root_ad4s1a.img

Примечание: если восстановление будет вестись с загрузочной флешки c FreeBSD или liveCD, то необходимо дополнительно указать темповую папку (указать свою)

export TMPDIR=/tmp/root

Практика восстановление бэкапа с файла

И так, вернемся к нашему примеру создания бэкапа в файл. Для теста я взял другой винчестер, подключил к серверу, загрузился с Frenzy LiveCd (или Install FreeBSD CD). Разбил винчестер, создал в папке tmp каталоги для монтирования разделов hdd на который будем выполнять перенос. Настроил сеть, создал каталог /tmp/backup, куда примонтировал NFS-шару с ранее залитым на нее бэкапом системы.

Для начала создадим в ОЗУ виртуальный диск (я делал размером 200 МБ), и назначим его для TMPDIR (при восстановлении незапакованого дампа размер занятого пространства в  TMPDIR составлял 134 МБ, а при восстановлении запакованого дампа, всего 18 МБ )

Для восстановления запакованого образа раздела, используем следующие команды

gzip -cd  /mnt/backup/root.dump.gz | ( cd /mnt/root ; restore -rf - )
gzip -cd  /mnt/backup/usr.dump.gz  | ( cd /mnt/usr ; restore -rf - )
gzip -cd  /mnt/backup/var.dump.gz  | ( cd /mnt/var ; restore -rf - )

Для восстановления не запакованого образа раздела, используем следующие команды

 

cd /mnt/root; restore -rf /mnt/backup/root.img
cd /mnt/home; restore -rf /mnt/backup/home.img
cd /mnt/usr; restore -rf /mnt/backup/usr.img
cd /mnt/var; restore -rf /mnt/backup/var.img 

 

На этом все. Перегружаем систему, при условии, что вы установили загрузчик в процессе разбивания винта, у вас загрзится полноценная рабочая FreeBSD

Ссылки

dump restore 


Webit.in.ua 2013