Backup/System Restore

[millpond]

I've noticed that there are many utils for backup, with 'snapshots' in the newer releases.

What I am looking for is something like the traditional system back and restore for Win, but with Buster/Sid.

I want to be able to apply updates, and if they dont work, roll them back.

I would prefer the files for this to be kept on an NTFS drive, so preferably something in a tar or tgz file.

Any recommendations with easy to follow instructions????

(I've done rsync in the past, but it made a mess of things!)

[Head_on_a_Stick]

https://packages.debian.org/stretch/snapper

[barlafuss]

Whuau!! Very interesting. Follow.
Thanks

[millpond]

https://packages.debian.org/stretch/snapper

https://www.thegeekstuff.com/2014/03/snapper-command/

It might as well be written in Ukrainian cyrillic.

Gives no clue as to size of files, or the percentage of space required.
No gui either.

I could probably script this if there was a better faq on this - and i would certainly want to avoid anything PAM related to a backup.

Not my first choice (I did wipe it from the system) but will try if its the ONLY option for this....

[Segfault]

My personal approach is completely different. Back up user files, databases and system configuration. These are enough to restore a system in case it is completely lost due to some disaster like hard drive failure. Backing up the whole system is slow, produces huge files, there is no thrill in it, either.

[Head_on_a_Stick]

if there was a better faq

Is your search engine as broken as the rest of your system?

https://en.opensuse.org/openSUSE:Snapper_Tutorial

[Ardouos]

Don't you need to use brtfs for snapper? Or can other file systems use it?

Edit:
Nvm, got my answer here:

Does snapper support ext4?

Yes, but only experimentally and you need a special kernel and e2fsprogs. For more information see the next4 project.

Source: http://snapper.io/faq.html

[Segfault]

rsnapshot works on any filesystem and uses hard links, no multiple copies of same files.

[llivv]

e2image
if it fits in your taste..
if not no need to commet further with regards to it for my benifit..
Unless you like that kinda thing....

[millpond]

if there was a better faq

Is your search engine as broken as the rest of your system?

https://en.opensuse.org/openSUSE:Snapper_Tutorial

1. Thank you for your recommendation. It showed me that snapper was totally useless for my needs. As to DDG, well, sometimes its not up to par, by missing a few links. Alot like my system, but its working fine for my needs, thus the need to back it up before implementing fixes. Though I cannot but help remember my old boss who told me when I asked him if it was alright to remove an inch of dust from the circuitry of a 5kw transmitter: "If it aint broke, dont fix it".

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

[millpond]

rsnapshot works on any filesystem and uses hard links, no multiple copies of same files.

rsnapshot seems to be based on rsync, burt I believe it will get permissions futzed up on an NTFS system.

[millpond]

e2image
if it fits in your taste..
if not no need to commet further with regards to it for my benifit..
Unless you like that kinda thing....

Indeed: Thank you.
https://superuser.com/questions/641903/ ... m-metadata

Looks interesting.
But confusing. Metadata vs new -a option. I have the qemu utils so that is not a problem. Examples given seem helpful, just need to know the how, what.whys of it, and what a metadata backup is!

I may need to script something that dumps tgz of main dirs, thoguh only pieces of lib and usr. Need to figure out the most volatile to save. Not perl or python, for example - too big and too easily replaced. So, are most of of the file dirs,as techically I can pull replacements directly from my archives. Up to date suggestions greatly appreciated. Google grows useless by the day, since 90% of everything appears for ubuntu. Great from my mint system, but thats a bit boring.It works.

Compiled to see if it works - fine . Just to recompile it into a deb package before install

[Segfault]

rsnapshot works on any filesystem and uses hard links, no multiple copies of same files.

rsnapshot seems to be based on rsync, burt I believe it will get permissions futzed up on an NTFS system.

NTFS I do not consider a usable filesystem, never crossed my mind one might count it in. There are other exotic closed source filesystems I didn't consider. These are Linux forums.

BTW, just checked, I have a user here, home directory backup is 11 GB. Four backups are 12 GB in total, thanks to hard links.

[llivv]

I don't know what ntfs would do to a qcow2 archive, I might think probably nothing.
than again probably something is more likely....
who knows .....
who cares.....
poor me.....
cest la vie .......
default is ext4
even if most of my partitions are xfs.
they are both turning into zfs clones with growing pains

[CwF]

I don't know what ntfs would do to a qcow2 archive, I might think probably nothing.

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

[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.