[Ubuntu] Backup en restore voor patching

[Mastakilla]

Hallo,

Ik wou hier even dubbelchecken of onderstaande werkwijze ok is...

Het doel is een Ubuntu 12.04 (en in de toekomst 14.04) te patchen (mogelijk incl kernel patches).
Er moet een rollback mechanisme zijn zonder hiervoor een live-cd ofzo te gebruiken (enkel als het echt heel fout loopt, wil ik eventueel een live-cd gebruiken).

code:

root@dcmilphlum172:~# fdisk -l /dev/sda

Disk /dev/sda: 77.3 GB, 77309411328 bytes
255 heads, 63 sectors/track, 9399 cylinders, total 150994944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000698c4

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     1953791      975872   83  Linux
/dev/sda2         1955838   150992895    74518529    5  Extended
/dev/sda5         1955840   150992895    74518528   8e  Linux LVM

root@dcmilphlum172:~# pvs
  PV         VG    Fmt  Attr PSize   PFree 
  /dev/sda5  vgos  lvm2 a-    71.06g 38.48g
  /dev/sdb1  vgapp lvm2 a-   678.00g     0 

root@dcmilphlum172:~# mount | grep 'ext4\|xfs'
/dev/mapper/vgos-rootvol on / type ext4 (rw,errors=remount-ro)
/dev/mapper/vgapp-datavol on /data type xfs (rw)
/dev/mapper/vgos-varvol on /var type ext4 (rw)
/dev/mapper/vgos-homevol on /home type ext4 (rw)
/dev/mapper/vgos-tmpvol on /tmp type ext4 (rw)
/dev/sda1 on /boot type ext4 (rw)

root@dcmilphlum172:~# grub-install --version
grub-install (GRUB) 1.99-21ubuntu3.17

Zoals je kan zien, gebruik ik LVM voor alle FS behalve /boot

Ik heb volgende website gebruikt als basis:
http://www.tutonics.com/2...ide-part-2-snapshots.html
Het enige verschil is dat deze website er van uit gaat dat je altijd een livecd gebruikt (wat ik niet wil).

Hieronder de werkwijze die ik in gedachte had

* backup

code:

dd if=/dev/sda1 of=/root/boot_backup.img
lvcreate -s -n rootsnapvol -L 3G --addtag @pre-patching_snap /dev/vgos/rootvol 
lvcreate -s -n varsnapvol -L 2G --addtag @pre-patching_snap /dev/vgos/varvol

* patchen (incl kernel) + reboot

* rollback indien nodig

code:

umount /boot
dd if=/root/boot_backup.img of=/dev/sda1
mount /boot
lvconvert --merge vgos/rootsnapvol
lvconvert --merge vgos/varsnapvol
/sbin/init 6

of

* cleanup

code:

rm /root/boot_backup.img
lvremove -v -f vgos/rootsnapvol
lvremove -v -f vgos/varsnapvol
lvchange --refresh vgos/rootvol
lvchange --refresh vgos/varvol

Vooral het stuk ivm /boot zou ik graag bevestigd zien. Moet ik bv wel een umount en mount doen? Of kan ik dit best laten?

[Hero of Time]

Doe voor /boot niet moeilijk en maak gewoon een tarbal van de inhoud. Sowieso, hoeveel gaat er nou veranderen? Er komen alleen bestanden bij als je de kernel update. Er is een minimale verandering in de grub bestanden, alleen de grub config verandert regelmatig (bij kernel updates/removals).

[Mastakilla]

Ik heb op een SUSE ooit het volgende probleem gehad na een rollback:
* Stage1 (MBR) gebruikt een offset naar de volgende stage.
* Doordat in de rollback sommige files overschreven waren (door een normale cp of untar), hadden die files een nieuwe locatie op de schijf gekregen, waardoor de stage1 offset niet meer naar de juiste file wees en het systeem niet meer bootte. Meestal is dit geen probleem als de oude file (zonder pointer) niet overschreven wordt, maar soms kan dit dus wel en dan zit je in de dikke stront...
* Dit kan je denk ik ook wel vermijden door na de rollback een grub-install te lopen en zo de mbr te updaten, maar weet niet zeker hoe precies..

vandaar dat het gebruik van "dd", zoals ook in de tutonics tutorial wordt aangeraden, mij eenvoudiger en veiliger leek...

[ Voor 4% gewijzigd door Mastakilla op 14-01-2016 14:36 ]

[InflatableMouse]

Je weet dat LVM snapshots (of is dat ondertussen opgelost?) een enorme performance impact hebben, voorals als je meerdere opeenvolgende snapshots maakt? Laatste wat ik weet is dat het ook nog redelijk buggy is. Maar mischien is mijn info achterhaald inmiddels. Het is volgens mij ook een beetje een brakke oplossing, omdat het snapshots mogelijk maakt op filesystems die dat eigenlijk helemaal niet ondersteunnen (Ext3, 4, XFS, etc).

Ik denk persoonlijk dat je er veel beter aan doet om een filesystem te gebruiken die native snapshotting gebruikt, als je dat perse wilt. Denk aan Btrfs of ZFS. De eerste is ook nog volop in ontwikkeling dus mischien ook niet de meest stabiele. Die laatste kan lastig worden als je je root partitie er op wilt hebben en er van wilt booten enzo. Of je moet op Solaris over willen stappen .

Andere opties zijn rsync snapshots. Kijk eens naar deze oplossing bijvoorbeeld. Dit kan ook, is op perl gebaseerd maar volgens mij functioneel hetzelfde als de eerste die gewoon in bash is geschreven.

dd is hopeloos inefficient voor backups als je het mij vraagt. Het pakt alles van een partitie of disk, sector voor sector, zonder ook maar enige vorm van intelligentie. Een partitie die 20G is, en maar 8G aan data bevat, zal gewoon voor de volle 20G gebackupped worden. Terugzetten met dd beperkt je ook in de mogelijkheden, of kan het je in ieder geval lastig maken.

Maar ik begrijp je sowieso niet helemaal als ik heel eerlijk ben. Je wilt rollback mogelijkheden als je onder andere je kernel patched. Dat gaat toch vanzelf? Kernels worden niet overschreven, je moet er sowieso voor rebooten, dan kies je in grub de vorige?

Je wilt ook niet van een live CD booten, waarom niet als ik vragen mag? Voor sommige updates moet je sowieso al rebooten, of in ieder geval X uitloggen/inloggen.

De meeste packages (als je weet hoe het moet, sommige kunnen lastig zijn) kan je rollback van doen zonder reboot.

Ik denk dat je het jezelf mischien wel gewoon te moeilijk maakt voor een probleem dat helemaal niet bestaat of in ieder geval niet zo groot is als je denkt?