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" root@raspberrypi.local:/ rpi_backup/

Where rsync-exclude.txt contains:



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!


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


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.

New contributor
binki is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

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.

  • Thanks for your answer. As I understood it, goldilocks stated that it is possible to also restore the files to a new card. I did not backup my boot partition. So is there any chance to use my backup? – jake Jan 7 at 3:29
  • @jake IF the backup and new image have the same kernel it would work if the PARTUUID are modified to match. – Milliways Jan 7 at 3:31
  • They are the same. I will try to understand PARTUUID tomorrow. Could it also be a problem that I backuped with another user (on my Ubuntu machine)? Thanks! – jake Jan 7 at 3:34
  • 1
    @jake If you can boot to emergency mode and re-mount the root in rw mode sudo apt-get update; sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel will put it back to the latest supported kernel/bootcode. – Milliways Jan 7 at 3:38
  • I have never had any success using rsync to a remote machine, but it SHOULD work to a Linux machine if the permissions are right. – Milliways Jan 7 at 3:40

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!

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.