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.