Linux (arch) backup

[PDifolco]

Hello guys
My Cachyos boot drive committed suicide yesterday (unreadable chunk tree I tried everything in chroot to no avail), I had to reinstall...
So I would like to do a full post-install backup of my packages (gaming, office, utilities etc.), I see that there are several methods,
I'd say simplest would be with dd to save everything from time to time, but it takes up space (well I have a 4TB HDD for that anyway)
What would you advise me?  

[Kilrah]

Backup your home folder and maintain a script that installs all the packages you need / does any system-level config changes. That way you can fresh install, copy the home folder back, and run the script to install what you need.

I tend to also backup /etc just in case I forgot something and need to look up what was done.

[ieleja]

/etc

/home

/root

/var — partly

folders with custom scripts, VMs, your system specific places 

 

[PDifolco]

21 minutes ago, Kilrah said:

Backup your home folder and maintain a script that installs all the packages you need / does any system-level config changes. That way you can fresh install, copy the home folder back, and run the script to install what you need.

I tend to also backup /etc just in case I forgot something and need to look up what was done.

Naaah that's for experienced disciplined professionals that end up using Nix !  I'm a lazy noob, don't remember half of what I did anyway...

6 minutes ago, ieleja said:

/etc

/home

/root

/var — partly

folders with custom scripts, VMs, your system specific places 

 

Could I reinstall that if the whole btrfs system is failing ? I don't care for personal files they're on other medias, just want to avoid the hassle of reinstalling OS + software + config + customization - already hated it with Windows!! 

[Kilrah]

3 minutes ago, PDifolco said:

don't remember half of what I did anyway

Well that's the point, now that you're reinstalling anyway you can document it

 

3 minutes ago, PDifolco said:

already hated it with Windows!! 

I mean it's not much different here, a bit easier on linux since there are fewer places settings are stored in but in the end a system is a system, if you want 100% and with minimal effort you have little choice but to make a full image regularly...

 

 

[PDifolco]

1 minute ago, Kilrah said:

Well that's the point, now that you're reinstalling anyway you can document it

 

I mean it's not much different here, a tiny bit easier but in the end a system is a system, if you want 100% and with minimal effort you have little choice but to make a full image regularly...

Which was my point : what's the better way to make a full image ?

I've already spent some hours reinstalling most of the stuff, now is a good time to do it

[Kilrah]

The way I do it is boot a live linux distro from USB and zstd the drive into an image file on an external drive/network storage

 

That's a thing that's easier on Windows, can just use something like Macrium reflect to make a consistent image of a running system, on linux good luck doing the equivalent

[OhioYJ]

2 hours ago, PDifolco said:

What would you advise me?

The script as @Kilrah mentioned. There just isn't any reason I would try and backup any of my Linux systems. The install just takes no time at all. I took a little bit of a time one time during one of my installs, and made a script. Now when I install, it runs installs all my apps, creates my short cuts, etc. The script runs and installs everything in a matter of minutes. There is very little I need to do manually afterwards. Honestly if I backed up my home folder as mentioned, I probably wouldn't be doing anything manually. 

[Mockenmeyer]

Timeshift is installed by default I do believe, and it backs up on a schedule that you can set.

[Nayr438]

10 hours ago, PDifolco said:

Naaah that's for experienced disciplined professionals that end up using Nix !  I'm a lazy noob, don't remember half of what I did anyway...

Could I reinstall that if the whole btrfs system is failing ? I don't care for personal files they're on other medias, just want to avoid the hassle of reinstalling OS + software + config + customization - already hated it with Windows!! 

If reliability is a concern id really consider using XFS or EXT4, we specifically use these two filesystems for reliability reasons with a preference for XFS.

 

Don't really have any input on backup, tarballs will however store filesystem metadata so if you want something smaller than a direct disk copy (DD), then that could be an option. A tarball may require some additional intervention on restore however.

[NoLeafClover]

I will second tarballs, it's a tried and trusted method going back decades and can store filesystem metadata, including extended attributes. But it can be a lot more involved and,  as @Nayr438 suggests, it may need additional work after a restore. Since it works on the filesystem level, if any filesystem UUIDs change - and they will if recreating the filesystem - then you will need to ensure "/etc/fstab" is updated accordingly after a "restore".

 

My usual "backup to a tarball" process for a root filesystem would be to first boot from a live distro and mount the partition to be backup and the destination backup drive somewhere, let's say "/mnt/rootfs" and "/mnt/backup" respectively. You can then "cd" (as root) into "/mnt/rootfs" and run something like:

tar --acls --xattrs --xattrs-include='*.*' --numeric-owner --one-file-system --exclude='lost+found' -capSf /mnt/backup/rootfs-backup.tar.zst .

which will make a Zstd compressed tar archive of the filesystem tree (you can use ".xz", ".gz", ".bz2" etc). If using SELinux, you can also add "--selinux" to preserve SELinux labelling, though I would personally recommend to always relabel the file system anyway after a restore. To restore the backup, you run the reverse to extract, e.g.

tar --acls --xattrs --xattrs-include='*.*' --numeric-owner -xapf /mnt/backup/rootfs-backup.tar.zst -C /mnt/rootfs

 

Some of the parameters are already the default behaviour when running tar as "root" but it doesn't hurt to be explicit. You can find out details about what they do with "man tar". If you're backing up a data/storage partition or directory you can do it w/o rebooting to a live-distro environment. You may be able to get away with doing it on the root filesystem as well since many of the mutable directories will be mounted as virtual filesystems and "--one-file-system" will ensure mounts are not processed (e.g. "/proc", "/sys", "/run", etc). But an offline backup of the rootfs is the safest way to ensure nothing changes while the backup process is taking place.

 

If you're using Btrfs, one option would be to create a snapshot (defaults to read-only) of the root filesystem then back up the snapshot. You can then do this online, w/o rebooting or unmounting the filesystem.

 

I was, in fact, planning on resurrecting the above quoted Btrfs thread as I've been cautiously trialling it out (w/o Btrfs RAID) for the last while and have overall a lot of positives to say and little negative. Some of the mentioned caveats in the thread still remain and there are some "bewares", but snapshots, subvolumes, and Btrfs send/receive have been a game changer, especially for the OS partition. I'm still mostly relying on ext4 for bulk storage, though, for now.

[PDifolco]

Ended up with the simple dd option, copied all of my Linux drive to my HDD as an image, and realized a using a full 2TB drive for 40GB used isn't smart lol 

So I tar-ed the image which is back to 25GB now

All of this wasn't that long, maybe 1 hour total , and I can reduce my partition size to make things faster

 

The tar method is good too, but requires booting on a live env, chroot-ing, it's more work, dd and tar are a basic script running in the background and I can still use the pc

Making an install script is definitely the smarter method, will do it next time I do a full install!

Thanks for the ideas !

 

[NoLeafClover]

7 hours ago, PDifolco said:

dd and tar are a basic script running in the background and I can still use the pc

Running online "dd" on a mounted partition (or a drive which has a mounted partition) is not a good idea and carries significant risks. "dd" will do a bit-for-bit image of the drive/partition (hence why the resultant images are large, as this includes the free space). This will include the file system itself and its data structures. If any process performs changes to the data - and inherently the file system - while imaging is being performed the resultant image could have, at best, corrupted file data or, at worst, broken file system structures that could result in being unable to mount the restored partition.

 

Similar risks exist with "tar" but since it operates at the file system level, not the block level, data corruption as a result of files being changed at the same time as them being archived is the primary concern. So in this regard "dd" is a significantly riskier approach.

 

To ensure proper integrity of the backup on an online partition, the process needs to be atomic. If the atomicity of the operation cannot be guaranteed, the next best thing is to either remount the partition as read-only and back it up (e.g. if archiving) or unmounting it (i.e. taking it offline) first and imaging it with "dd".

 

This is why I highlighted that bulk storage / data mounts are generally easier to deal with as they can be temporarily remounted read-only and archived quite easily, e.g.

mount -o remount,ro /path/to/mountpoint

For the root file system, this isn't easily done for obvious reasons - you can, but processes might complain when they try to write. This is where something like Btrfs' snapshots can be really useful as creating a snapshot of a subvolume is an atomic operation and guarantees that the snapshot will be in a consistent state. The snapshot can then be archived as usual, w/o taking the system down.

 

7 hours ago, PDifolco said:

Making an install script is definitely the smarter method, will do it next time I do a full install!

Agree. This is a good approach for provisioning a system with an identical "desired state", but is not the same as a backup. NixOS has a way of making declarative builds, which is pretty cool. Not saying you should migrate, just sharing an interesting observation.

 

Edit:

 

For completeness, backing up user data, e.g. games, documents, etc, is a relatively low risk exercise and unlikely to cause trouble even with "tar" under a read-write mount, provided you're not actively modifying anything. Tools like Deja Dup (uses duplicity) or even straight "rsync" are generally pretty useful and can be used for "incremental" backups/copies with varying levels of simplicity. In the most basic scenario where you want to basically do a 1:1 replica of directory "A/" into directory "B/", then rsync is pretty good at doing that and only copying and removing what has changed - it uses file metadata to track changes by default, but comparison can also be done with checksumming albeit slower.

[xAcid9]

On 2/17/2026 at 5:39 AM, Kilrah said:

That's a thing that's easier on Windows, can just use something like Macrium reflect to make a consistent image of a running system, on linux good luck doing the equivalent

Is it not possible just use Macrium to image your Linux drive/partition?

[Kilrah]

3 hours ago, xAcid9 said:

Is it not possible just use Macrium to image your Linux drive/partition?

Sure but then you must be running a Windows system to use it, so which defeats the benefit of imaging the running system

[NoLeafClover]

Another option I forgot to mention, which is similar to snapshots on Btrfs, is the LVM snapshot functionality. Creating an LVM volume snapshot is also an atomic operation and will ensure the snapshot is consistent. This can be done on a running system. The snapshot can then be imaged with standard tools such as "dd". Of course, the prerequisites here are that:

• the drive is set up to use LVM (can be the default for many installers)
• there is enough free space in the volume group for standard COW snapshots, or LVM thin provisioning is used (rarely default)

The extra space in the case of COW is not for "copying" the volume, rather for diverging changes with the origin. The initial snapshot will not consume any additional space, but as the contents diverge from the source, extra space will be needed to accommodate these changes.

 

This has the advantages that it's independent from the filesystem used on the volume, but can be tricky to set up and work with in the non-thin provisioned case. The resultant snapshot can be imaged with "dd" in the exact same way as a drive or partition. LVM structures are not going to be part of the image, so a restore would involve creating a suitable LVM volume or standard partition to write to. Or simply restore the snapshot with LVM tools, if an image file is not required.

 

So various tools exist and have been around for a very long time, but it's not always a "point and click" solution. If the filesystem supports snapshotting that's likely to be the easiest option for an online mount.

 

I don't know how or what Macrium Reflect does on Windows, but the general caveats with imaging an online disk/partition are not unique to Linux and apply to any OS on a partition/volume/etc that is mutable. So there clearly must be a facility in place to ensure no updates are taking place during the imaging or such updates are taken into account so that the image is consistent.

[xAcid9]

2 hours ago, Kilrah said:

Sure but then you must be running a Windows system to use it, so which defeats the benefit of imaging the running system

I mean tools like HBCD/DLCBoot exist.

 

Just drop the ISO into your Ventoy USB drive and boot into HBCD WinPE.

It come with Macrium 7.5 by default.

[Kilrah]

5 minutes ago, xAcid9 said:

I mean tools like HBCD/DLCBoot exist.

 

Just drop the ISO into your Ventoy USB drive and boot into HBCD WinPE.

It come with Macrium 7.5 by default.

Which is similar to what I was suggesting OP does for their linux system with other tools. 

 

I only mentioned as a side thing that Macrium on Windows has the advantage of being able to consistently image the running system precisely without having to boot another OS.

[PDifolco]

11 hours ago, Kilrah said:

Sure but then you must be running a Windows system to use it, so which defeats the benefit of imaging the running system

That's an idea I've a dual boot system 

But i suppose it's like making an image with dd, but with an offline linux

Kinda comparable to using tar on a live env too

[AtomicGlargh]

I would suggest saving the space and creating an ansible script.

[PDifolco]

3 hours ago, AtomicGlargh said:

I would suggest saving the space and creating an ansible script.

Please elaborate, wdym??

[AtomicGlargh]

https://docs.ansible.com/

It's the standard method for setting up a Linux system. You can have it install the packages you need and make any configuration changes. You'll want to play with it inside a VM until you tune it right.

 

There are plenty of modules to simplify things, but worst case it allows you to run shell commands.

[Mina G]

for regular backup use timeshift for imaging use clonezilla 

[PDifolco]

Finally I think that in case of system crash/corruption, I have Limine snapshots, and else  simplest is to just reinstall the OS, it takes like 3 minutes booting on my USB-C live Ventoy NVme ("old" Gen4 500GB drive lol) and installing ! Have to do a script to install packages but I don't have that much installed (Steam, Lutris, LibreOffice, Gimp, a pack of gaming tools Lact/lsfg-vk/mangohud/Goverlay plus some system utilities)

Fully imaging the system takes ages and alot of space as I have it installed on a 2TB partition, 90%% of which is empty...Can do it once a month, dd seems fine for that, then I ark it for storage saving

For personal files and stuff I discovered Pika backup, it's really easy to use and suits me well