Restore backup failed (using rsync)

Question

I backuped my RPI following goldilock's answer (Can a Raspberry Pi be used to create a backup of itself?). Running this:

rsync -axHv --delete --exclude-from=rsync-exclude.txt --rsh="ssh" [email protected]:/ rpi_backup/

Where rsync-exclude.txt contains:

/proc/*
/sys/*
/dev/*
/boot/*
/tmp/*
/run/*
/mnt/*

.bash_history
/etc/fake-hwclock.data
/var/lib/rpimonitor/stat/

My sd-card turned into trash so I wanted to restore my backup. I copied a raspbian image to a working sd-card (I checked it with fsck.ext4 and badblocks -vsn), booted my RPI with it once and then run:

sudo rsync -av --delete-during /something/rpi_backup /mnt/sdcard_partition2/

Then I tried to boot my pi, but ended up in emergency mode. I got some errors like failed to mount Configuration File System etc.

What did I do wrong? Any help is appreciated!

Answer 1

I specifically reactivated my never used account to answer this question, because I was having the same problems last week and felt like other people will too./rant

About the actual problem, using the explanation about ssh from Can a Raspberry Pi be used to create a backup of itself? misses a crucial point - rsync does not properly preserve the ownerships (even though the '-a' option states that it does) if there are user id missmatches between the 'host' and 'target' system (there is a user 'foo'/id:1200 not present/different id on the other system).

Thats why, if you try to do an rsync rootfs copy of your raspberry on you own PC, you will get all the files belonging to the pi user, or the root user if you ran rsync with sudo. That is unless you tell rsync to save the user permissions as

--numeric-ids

As for the actual error that is presented if you don't use --numeric-ids, in short the whole backup created has the file owner set to 1 user (the pi one) - easily verifiable with a simple 'find backup_path -user any_other_user' which will yield no results. If this backup is used for restoring, one of the first systemd units ran at boot - systemd-remount-fs.service will fail because the executable it runs, owned by the pi user, tries to (re)mount the rootfs, which it cannot do because of lack of permissions, then the rootfs gets mounted with read-only permission which fails a lot of other units which cannot write to the rootfs, in the end you get presented with systemd's emergency mode.

When the numeric ids option is used, it should also be possible to properly transfer the installation to another SD card, with the proper modification of the cmdline.txt and /etc/fstab files with regards to the new PARTUUIDs.

Answer 2

Most likely a mismatch between /etc/fstab and /boot/cmdline.txt.

Other possible errors are a mismatch between the kernel version and modules.

The process was designed to BACKUP and RESTORE to the SAME SD CARD - not a new image. It was also written before the adoption of PARTUUID.

If you overwrite the boot partition with the contents of that on the old card it may work, but you would still need to modify PARTUUID entries in BOTH the files above to match your SD Card.

sudo fdisk -l /dev/mmcblk0 will show the Disk identifier: of the SD Card. Ideally this should be done on a fresh image (before restore) or an a mounted SD Card.

Answer 3

I'm afraid the main issue here was as dumb as it was simple.

I just did not run the rsync ... command as root:

So rsync set the owner of all directories an files to UID=1000 (pi) instead of UID=0 (root), so there was of course trouble with the permissions.

The answer of @Milliways was still very helpful to understand some stuff. Thanks!