Backup/System Restore

[llivv]

I *think* I have done this. I've carried with me a qcow image on a usb Fat32 and ntfs. A remote location situation.

The newest e2image man page shows in an example that a qcow image can be bzipped compressing it even further. So probably can also be compressed with lzma making a .xz archive, as well.
Interesting for backup stratagies, in my op inion

[CwF]

Yes, I didn't offer up an explanation, but it is my method. From a usb with a minimal rescue style OS there is space for many images. Prep of the image, ie defrag (even on a ssd) for *those* file system types and a bleachbit to zero empty sectors on ext4's allows qemu-image to compress the images pretty tight. The same utility can read and write and convert to and from device (sdx) and file (qcow2), dd style. I even use it for segregated/isolated user data that is then mounted dynamically and temporarily to vm's as virtual usb drives. I layer vm's on basefile qcows (backing file) of 1.1 to 1.7 GB, uniqueness layer with domain id changes etc. adding 20-50MB, and lastly the runtime layer that is disposable without losing anything.

Generic backup formula:

Code: Select all

qemu-img convert -p -c -O qcow2 /var/lib/libvirt/images/name.qcow2 /pool/VM/meadow/cows/name_state(backing,rc#-(fat,bleached,stained))-YYWW.qcow2

from disk:

Code: Select all

qemu-img convert -p -c -O qcow2 /dev/sdx(/dev/disk/by-*/*) /pool/VM/meadow/cows/name_state-YYWW.qcow2

options -p (progress %) and -c (compression) are costly, and with unprepped disk -c won't do much. Use two steps, device to raw img, then raw to qcow with -c helps.
From image:

Code: Select all

qemu-img convert -p -O raw /wherever/image-name.qcow2 /dev/sdx(/dev/disk/by-*/*)

Extras, virtual usb disk:

Code: Select all

virsh attach-disk VMNAME /pool/VM/pasture/cows/slop.qcow2 sdx --targetbus usb --subdriver qcow2

And yank it:

Code: Select all

virsh detach-disk VNNAME sdx

...and of course there are ways to peek into these images without running a vm. Many images in /var/lib/libvirt/images/ are actually links to elsewhere and in some cases a block devices. So for me, the qcow backup of a encrypted three partition hypervisor is 25-50GB, and I can't get there in a single step, first is <120GB disk size. All OS's and user data is separate, if not then 'stained'. Without VM use, only qemu-utils and a few dependencies is needed on that usb rescue style device. You can't image the disk you're running from...so for a single box with no alternate boot options we're back to the standard question of how to back up.

[llivv]

Yes,
[...] | [...]
only qemu-utils and a few dependencies is needed on that usb rescue style device.

You can't image the disk you're running from...so for a single box with no alternate boot options we're back to the standard question of how to back up.

Excellent points..
Regarding the single box install issue,
I always take fore granted that a backup strategy includes an alternative way to boot a machine,
so the filesystem(s) can be attended to while unmounted.
My method is to keep a second install of the Debian Release in question.
Than if, I encounter issues on either one I can reboot to the other when necessary.
It is even more important when there are significant changes implemented to the filesystem(s) being used with Different Releases.
Using the same methods on the same filesystem(s) from a different releases can have unforeseen complications.

[Head_on_a_Stick]

Now for my recommendation: Alka-seltzer - for your obvious dyspepsia.

Ha!

My caustic tone is entirely in keeping with the spirit of these boards, probably best not to take it personally.

[millpond]

Now for my recommendation: Alka-seltzer - for your obvious dyspepsia.

Ha!

My caustic tone is entirely in keeping with the spirit of these boards, probably best not to take it personally.

I just checked, and it appears that macrium Reflect which I use on my Win systems, and can handle at least 200Gb should also work on a Linux drive, though it cannot slectively restore files. Somehwere around I should have Acronis on a PE which should.

The thing with the qemu-backup is whether the Linux utils can handle 300Gb+ , about what I need for this system, fully backed.
It would be to a USB 2Tb drive, that is normally disconnected, so diff incrementals might or might not be feasible.

I realize these are the debbils spawn, but then again so is Lennart.

[CwF]

The thing with the qemu-backup is whether the Linux utils can handle 300Gb+ , about what I need for this system, fully backed.

I did say segregated...I wouldn't dream of using qcow as a backup for a 300+GB data set unless it operated in a vm as a qcow. Although I'm sure it would handle it just fine. The idea of 'fully backed up' is not necessarily a single solution, as said more than once in this thread. Cleaned of junk my 'fully backed' system (OS) could be maybe 12 GB. As said, the building blocks are gigs. Terabytes of user data is an entirely different issue.

[tyler2016]

How about dump/restore? The package name is dump. dump can write to standard out which can be compressed, sent through an ssh tunnel, etc.

Example:

Code: Select all

root # dump 0f - /mountpoint | gzip > full #full
root # dump 1f - /mountpoint | gzip > delta # changes since last level 0

Dump levels are from 1 to 9, so you have a lot of flexibility.