My personal Linux backup strategy

General Discussions
,
61

Ricardo, since you don’t want to split your backup drive into partitions for each of Windows and Linux, keeping NTFS as the filesystem type is not an issue with using rsync for doing the backups of the Linux installation.

All you need to do is have only 2 top-level directories on your backup drive:

  • one for Windows
    (call that ${pathToBackupDiskRoot}/win),     and

  • one for Linux
    (call that ${pathToBackupDiskRoot}/nix)

You can then specify ${nix} as the target root for your Linux backups. Without confusing you with my full backup script, the command that I “build” is the following:

	COM="ionice -c 2 -n 7 rsync \
		${limitThruput} \
		${doUpdate} \
		${doCheckSum} \
		${showProgress} \
		--one-file-system \
		--outbuf=Line \
		--recursive \
		--delete-during \
		--preallocate \
		--links \
		--perms \
		--times \
		--group \
		--owner \
		--atimes \
		--devices \
		--specials \
		--verbose --out-format=\"%t|%i|%M|%b|%f|\" \
		--whole-file \
		--human-readable \
		--protect-args \
		--ignore-errors \
		--msgs2stderr \
		${EXCLUDES} \
		./ ${PathMirror}${dirC}/"

Most of that is options, as you can see, but the last line is the critical piece.

  • “./” is the reference to the root of your Linux OS, assumed to be $PWD
  • “${PathMirror}${dirC}/” is the reference to the backup image target “root”, i.e the path to reach the above-mentionned “${nix}” on the backup disk (note the “/” at the end is critical here).

If you have any questions about the above, feel free to ask.

If you want to see a bit more about my backup script, you can review the discussion and URLs provided here:


But I think the big question is

  • whether you prefer to keep a full system snapshot (moment in time) at each backup,

or …

  • whether you feel confident enough in your habits that you only ever need the very last backup to reclaim a recent mis-step, immediately upon doing that mis-step in order to recover the previous file version from the backup snapshot, if you don’t have that particular file under separate revision control.

That is fundamentally the bigger question.

My own backups are from the stance that I only ever need my last snapshot (never needed anything else). Depending on your own context, if you need different time-based snapshots, then you would need to set the backup target as directory having a date-based name, such as

  • ${pathToBackupDiskRoot}/nix/20260426/
3 Likes
62

Ehi @ericmarceau thanks for the tips!
My worries about your idea are concerning about Unix permissions over files and directories: Does a Rsync backup from an Ext4 or XFS file system fit on a NTFS partition preserving original permissions? Will I be able to restore my Linux installation in case of disaster? Nowdays with Timeshift over a Ext4 partition this is garanteed.

2 Likes
63

My apologies, Ricardo. You are correct about the loss of those properties and permissions.


Changing gears to different context …

I know you mentionned using dd as your chosen tool, in your OP. However, have you considered using ustar or pax instead?

ustar and pax would be much better choices in that they would not even attempt to read those empty blocks and skip them altogether, focusing only on collecting data blocks specific to each of directories and files, all the while keeping the attributes.

I distinguish between the older tar and the newer ustar and pax because the older tar relied on the host system being aware of the usernames associated with UIDs, whereas, the latter 2 will report the proper usernames and groups when requesting a directory listing of the archive file contents.

The form that I used in the past, pre-rsync, was

( cd "${sourceDir}" ; tar --format=ustar -cvf "${backupRoot}/${datedImage}" ) >"${datedLog}" 2>"${datedErr}"

One “gotcha” to watch for:

  • ustar is POSIX-compliant
  • star is a “relaxed” alternative, deviating from POSIX

I’ve never adopted star, so can’t tell you much about it, but it may be attractive depending on your context. You would have to research that yourself.

1 Like