1

I have a Raspberry Pi 2 running Raspbian Jessie. It is being used as a reverse proxy for my various self-hosted services, it is running openHAB, it is my mosquitto server, etc.

I would like to create incremental backups of the system just in case the SD card becomes unusable (or some other catastrophe happens).

I have another server running Ubuntu 16.04 with a large HDD that I would like to use to store the backup.

I am essentially following the idea of this answer by goldilocks

Here is my backup script, which is run from the Pi:

#!/bin/bash
sudo rsync -aHv --progress --delete-during --rsync-path="sudo rsync" -e 'ssh -i /home/pi/.ssh/id_rsa' --exclude-from=/home/pi/live_backup_script/rsync-exclude.txt / htpc@htpc:/media/htpc/data/backups/rpij/live/
sudo rsync -aHv --progress --delete-during --rsync-path="sudo rsync" -e 'ssh -i /home/pi/.ssh/id_rsa' /boot/ htpc@htpc:/media/htpc/data/backups/rpij/BOOT_PART/

I then create a tar.gz file of the live/ and BOOT_PART/ directories every day, and delete the old ones.

I have run rsync as root on the Ubuntu system in order to maintain the correct ownership of the files. However, obviously all of the users on the Pi don't exist on the Ubuntu system, and therefore a file owned by a user such as openhab becomes a different user like pulse. Thus, my question is two-fold:

  1. How can I restore such a backup to get a working Raspbian system? Said another way, will the ownership of the files be correct once copied and booted by the Pi?

  2. Is rsync preserving ownership using the numeric UID and GID? If so, if there is a UID on the Pi that isn't tied to a user on the Ubuntu system, will this cause problems?

E. Schiesser
  • 168
  • 2
  • 7

1 Answers1

0

therefore a file owned by a user such as openhab becomes a different user like pulse

This is because the UID number for openhab on the Pi is evidently the same as the number for pulse on Ubuntu. A variant on this is when the number isn't attached to any user account (they are all listed in /etc/passwd, which IMO is sort of an unfortunate name since most of the information in it has nothing to do with passwords). In this case, the file will just have that number associated with it. I.e., when you see this, it isn't because there's a user named 1234, it's because the file came from some other system with a user number that's not listed locally.

[Technically there can be a user named 1234 but never mind that.]

Is rsync preserving ownership using the numeric UID and GID?

Yes, because what's really associated with a file is the numerical ID. Text names are found via a lookup on /etc/passwd -- you can see this if you run:

strace stat whatever.file 2>&1 | grep passwd

You'll find an open("/etc/passwd" .... I would guess this is via the C library getpwnam() call, which interestingly does not involve an actual syscall -- other than those involved in opening and reading /etc/passwd.

If that meant nothing to you, don't worry. The point is UIDs and GIDs are fundamentally numbers, not names. Those numbers are kept intact.

The superuser (root) is always 0, but there is thus an obvious security concern in copying part of a filesystem from one system to another, if e.g., bob's UID number turns out to be larry's and larry can access the copied data. But it is easy enough to prevent this, particularly if you are taring it all into a single file.

will the ownership of the files be correct once copied and booted by the Pi?

Because of all this, you want to make sure a system backup includes /etc/passwd so that if used to restore there is the correct local correlation between names and numbers. Which it presumably does, and in which case yes, the ownerships will be correct.

goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • Great answer. You've shed some significant light on a solution. Could you perhaps link to a resource for restoring the backed up data to a working image? For instance, in [your linked answer](https://raspberrypi.stackexchange.com/a/5492/37832) you link to [this answer](https://raspberrypi.stackexchange.com/a/29952/37832) about creating an empty disk image. This is a start, but it is not clear how to get from there to a bootable image. It would be great to have this all in one place. – E. Schiesser Nov 16 '17 at 19:34
  • I won't have time until tomorrow to do that properly, but basically, you don't need to create a complete image, you can use a stock one to create the card, then reformat (`mkfs.ext4 ...`) the root partition and copy the backup in. There is a major caveat though: You have to make sure you include a `/lib/modules/x.x.x` that matches the kernel in the boot partition. – goldilocks Nov 16 '17 at 19:46