How could you possibly preserve file ownership in a backup (/etc)?

Question

I've seen a number of sources suggest it can be useful to back up /etc. E.g. the presentation "Supporting Debian machines for friends and family".

For any serious backup, we also need a well-defined restore process (which we can test periodically :-).

How do you restore these system files, from a backup which includes ownership information? Give an example of a working restore process. State any assumptions made. You may assume the backup tool of your choice, e.g. tar or etckeeper.

---

Example of files with specific owners:

$ ls -l|grep -v "root root"
total 2240
-rw-r-----.  1 root brlapi     33 Nov 15 21:32 brlapi.key
-rw-r-----.  1 root chrony    481 Nov 21 11:03 chrony.keys
drwxr-xr-x.  4 root lp       4096 Apr 18 10:58 cups
-rw-------.  1 tss  tss      7046 Feb  5  2016 tcsd.conf

Answer 1

The way I do it is to install etckeeper. It is well integrated in Debian and derivatives. Etckeeper takes care of remembering permissions (but not SELinux labels). Backing up /etc is then reduced to the well-understood problem of backing up a version control repository (e.g. git pull from /etc).

To restore the backup:

1. Perform a default installation (the same default installation as the original).
2. Install etckeeper and the requisite version control system.
3. Restore the backup of /etc (git clone and git checkout or equivalent). As pointed out by sourcejedi, you need to do this before installing any package that assigns user or group IDs dynamically.
4. Restore the list of installed packages and install them. Etckeeper doesn't keep track of that; on Debian and derivatives, use apt-clone, see How do I replicate installed package selections from one Debian system to another? (Debian Wheezy)).
5. Reboot.

Note that there are a few things that might not work if the hardware isn't exactly the same or if the filesystem has been reformatted, which tends to be the case when you're restoring a backup. To make the restoration work more seamlessly, ensure that you don't use unique hardware identifiers anywhere in your configuration (e.g. MAC address, disk serial number) or random identities (e.g. use filesystem labels, not filesystem or partition UUIDs).

Answer 2

This answer is a checklist of some issues which would need testing, having not seen them mentioned elsewhere. Now I can happily discount mentions of "backing up" /etc, which do not also detail how to restore it. I have not tested to see whether this checklist is complete.

The following steps also ignore the frequent version-sensitive & other changes I see in etckeeper during package upgrades, as not specifically mentioned in the question. At least there are probably simpler systems where that is not a problem, like routers running OpenWrt.

1. Assumption: this backup specifically includes /etc.
2. Assumption: you also know how you're going to handle any references to filesystems, e.g. which might have been re-created with a different UUID, in /etc/fstab.
3. Assumption: the target system does not include any extra users, when compared to the backup. E.g. it is a fresh install of the operating system, your initial user is created with the same name (and UID), and no additional services have been added to the OS during an upgrade. This is likely true within a Debian stable release, but certainly not reliable for a rolling-release distribution.
4. Assumption: the install process is fully deterministic w.r.t. assigned UIDs (package install order), and this is not affected by any new updates in the repositories. I believe the usual package managers are deterministic. Again, Debian stable is probably reliable, a rolling-release isn't, and between them lies an area of uncertainty. You could also arrange to run the exact same version of the installer, without access to update repositories (both during the restore and when you installed the original system).
5. You should have already installed the restore tool(s) for your backup :).
6. The steps below also assume Linux' traditional shadow password files. BSD systems use different filenames. Some special-purpose Linux systems have introduced a significantly different style.
7. Make sure you can boot into some "rescue mode", without using any password defined in /etc, and you don't need anything more complex in order to access the backup. We're playing with fire here. I don't know how disk encryption will handle this, although using the same password as the backup might help. Note the steps below will not work if run from a separate "rescue system".
8. mv /etc/ /etc.installer # can be removed later
9. mkdir /etc && chmod 755 /etc
10. ID_FILES=passwd group shadow
11. for i in $ID_FILES; do cp /etc.installer/${i} /etc; done
12. Now for each file i in $ID_FILES, you can restore /etc/${i} from your backup to the target system.
13. Now you can restore all the files, including their ownership information.
14. Now you can re-apply SELinux labels or equivalent, if necessary.

If the backup is an etckeeper repo (and no additional files), then step 12 is to copy/clone it to /etc and then run etckeeper init. You could probably skip steps 10-12.

OpenWrt

System config backup/restore is supported on OpenWrt routers, with a specific feature in the web interface.

On my OpenWrt 15.05.1 system, I see the only users owning files in /etc (or anywhere else) are root and nobody. It should be safe to assume that a fresh install of OpenWrt already includes these users.

I do not know if OpenWrt setups which have added extra users, would be handled correctly by this tool.