Однако близится день заморозки кодовой базы 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 освободится. Аналочично поступаем, если нужно вернуться в играм с обновлением.
Комментариев нет:
Отправить комментарий