Backup/System Restore

New to Debian (Or Linux in general)? Ask your questions here!

Re: Backup/System Restore

Postby llivv » 2019-01-22 07:04

CwF wrote: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
In memory of Ian Ashley Murdock (1973 - 2015) founder of the Debian project.
User avatar
llivv
 
Posts: 5488
Joined: 2007-02-14 18:10
Location: cold storage

Re: Backup/System Restore

Postby CwF » 2019-01-22 15:15

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.
CwF
 
Posts: 386
Joined: 2018-06-20 15:16

Re: Backup/System Restore

Postby llivv » 2019-01-22 17:27

CwF wrote: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.
In memory of Ian Ashley Murdock (1973 - 2015) founder of the Debian project.
User avatar
llivv
 
Posts: 5488
Joined: 2007-02-14 18:10
Location: cold storage

Re: Backup/System Restore

Postby Head_on_a_Stick » 2019-01-22 19:05

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

Ha! :mrgreen:

My caustic tone is entirely in keeping with the spirit of these boards, probably best not to take it personally.
User avatar
Head_on_a_Stick
 
Posts: 10321
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Backup/System Restore

Postby millpond » 2019-01-22 23:17

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

Ha! :mrgreen:

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.
millpond
 
Posts: 653
Joined: 2014-06-25 04:56

Re: Backup/System Restore

Postby CwF » 2019-01-23 00:46

millpond wrote: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.
CwF
 
Posts: 386
Joined: 2018-06-20 15:16

Re: Backup/System Restore

Postby tyler2016 » 2019-02-07 14:39

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.
tyler2016
 
Posts: 5
Joined: 2019-02-07 14:32

Previous

Return to Beginners Questions

Who is online

Users browsing this forum: No registered users and 7 guests

fashionable