среда, 16 мая 2012 г.

Делаем бэкап перед обновлением системы средствами LVM

Дошли руки до своего нетбука, который знакомый попросил одолжить на время. Перед тем как отдать нетбук я решил сделать полный бэкап системы, но потом не смог найти достаточно свободного места на домашнем компе, чтобы забэкапить весь диск целиком. Поскольку знакомому вполне подходил ноут без жесткого диска, то я просто снял винт и таким образов временно решил проблему полного бэкапа.

Однако близится день заморозки кодовой базы Debian в предверии нового релиза Debian Wheezy. Основные черты нового дистрибутива уже видны и по возвращении нетбука я хочу пробно обновить систему на нем, чтобы иметь представление, что меня ожидает при обновлении домашнего компа.

Чтобы не было неприятных сюрпризов перед обновлением, мне нужно сделать бэкап, причем желательно таким образом, чтобы была возможность возиться с "последствиями" обновления и иметь возможность быстро переключиться на стабильный Squeeze. Если делать это по-старинке, то мне придется делать зеркало системных файлов на домашний комп, причем в двух вариантах (стабильный squeeze и обновление на wheezy). Понятное дело, что восстановиться из такого бэкапа в полевых условиях не получится (если вдруг всплывет косяк, связанный с обновлением). Нужна возможность держать всю информацию на самом нетбуке, но проблема в том, что там просто нету столько свободного места, чтобы держать две полные копии системы. Потому я начал искать новое решение...

В общих чертах меня могла бы спасти BTRFS у которой есть поддержка снапшотов на уровне файловой системы (т.е. в снапшотах хранится только разница относительно базы, с которой они были созданы). Но btrfs еще в стадии разработки и спотыкаться об ее недоработки нет желания.

Далее вспомнилось, что в самом начале освоения LVM я пробовал делать снапшоты перед обновлением системы. Если обновление нужно было отменить, то приходилось монтировать снапшот и затем rsync'ом приводить систему в чувство. Но хочется чего-то проще. Что-то вроде сделал снапшот и если результат обновления не нравится - просто возвращаем исходное состояние нужному LVM тому, используя для этого соответствующий снапшот.

Пока искал выход нагуглил новость о том, что начиная с ядра 2.6.33 появилась возможность объединять LVM том и его снапшот - BINGO! - как раз то, что нужно мне и без лишних телодвижений.

Разбивка диска на нетбуке у меня не слишком мудреная:

/dev/sda1  /boot  ext2
/dev/sda2  LVM PV
/dev/sda3  SWAP

/dev/laptop/rootfs  /  ext4
/dev/laptop/home  /home

Посколько /boot находится вне LVM, то я сделал его копию:

# rsync -a /boot/ /boot~lvm/

Смотрим, сколько у меня места в группе томов (VG), еще не размеченного под логические тома (LV):

# vgs
  VG        #PV #LV #SN Attr   VSize   VFree
  laptop      1   2   0 wz--n- 156,2g  15,44g

Далее делаем снапшоты всех разделов:

# sync
# lvcreate -s -n rootfs-before -L 5G laptop/rootfs
# lvcreate -s -n home-before -L 1G laptop/home

После этого можно смело обновлять систему. Если потребуется откатить обновление, то создаем новый снапшот (чтобы разобраться, когда появится свободное время) и мержим старый снапшот и соответствующий логический том:

# lvcreate -s -n rootfs-after -L 7G laptop/rootfs
# lvcreate -s -n home-after -L 1G laptop/home
# lvconvert --merge laptop/rootfs-before
# lvconvert --merge laptop/home-before

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

Если в процессе обновления поменялось содержимое /boot, то после перезагрузки или при помощи LiveCD/LiveUSB его можно восстановить так:

# rsync -a --delete /boot~lvm/ /boot/
# rm -fr /boot~lvm
# update-grub

После завершения слияния, пространство, занятое под laptop/rootfs-before и laptop/home-before освободится. Аналочично поступаем, если нужно вернуться в играм с обновлением.

Комментариев нет:

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