From minfrin at sharp.fm Tue Apr 8 07:48:14 2025 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 8 Apr 2025 08:48:14 +0100 Subject: How do I restore using --fake-super? Message-ID: <5A1A94C9-8934-4457-9151-5BCBB66D2456@sharp.fm> Hi all, I have a backup that was created with --fake-super that I need to restore to a fresh partition on the same machine as the backup (source and destination on the same machine). The docs describe how --fake-super is used to make the backup, but none of the docs describe how you do the reverse and restore. Google is hallucinating some nonsense, so that's a dead end. Can anyone confirm what modification needs to be made to this command line to recover symlinks, permissions and owners: rsync -av --numeric-ids /mnt/backup/root/ /mnt/root/ [--what-extra-params-go-here] Note that both the source and the destination are on the same machine. Regards, Graham -- From paul+rsync at wurtel.net Tue Apr 8 09:04:42 2025 From: paul+rsync at wurtel.net (Paul Slootman) Date: Tue, 8 Apr 2025 11:04:42 +0200 Subject: How do I restore using --fake-super? In-Reply-To: <5A1A94C9-8934-4457-9151-5BCBB66D2456@sharp.fm> References: <5A1A94C9-8934-4457-9151-5BCBB66D2456@sharp.fm> Message-ID: On Tue 08 Apr 2025, Graham Leggett via rsync wrote: > > I have a backup that was created with --fake-super that I need to restore to a fresh partition on the same machine as the backup (source and destination on the same machine). > > The docs describe how --fake-super is used to make the backup, but none of the docs describe how you do the reverse and restore. The manpage says: --fake-super store/recover privileged attrs using xattrs so I would assume that also use --fake-super during restore? Paul From minfrin at sharp.fm Tue Apr 8 09:28:32 2025 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 8 Apr 2025 10:28:32 +0100 Subject: How do I restore using --fake-super? In-Reply-To: References: <5A1A94C9-8934-4457-9151-5BCBB66D2456@sharp.fm> Message-ID: On 08 Apr 2025, at 10:04, Paul Slootman via rsync wrote: >> I have a backup that was created with --fake-super that I need to restore to a fresh partition on the same machine as the backup (source and destination on the same machine). >> >> The docs describe how --fake-super is used to make the backup, but none of the docs describe how you do the reverse and restore. > > The manpage says: > > --fake-super store/recover privileged attrs using xattrs > > so I would assume that also use --fake-super during restore? Unfortunately all combinations of --fake-super that I have used so far have had the effect of backing up the backup, not restoring the backup. To be explicit, my source backup directory has the user.rsync.%stat attribute as expected indicating a correct backup. My destination directory also has the user.rsync.%stat directory, indicating that I have just backed up my backup, I have not restored my backup. Can anyone confirm the correct restore command line option, as opposed to the backup command line option? Or to put this another way, how do I "do then undo", and not "do twice"? Regards, Graham -- From minfrin at sharp.fm Tue Apr 8 10:34:09 2025 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 8 Apr 2025 11:34:09 +0100 Subject: How do I restore using --fake-super? In-Reply-To: References: <5A1A94C9-8934-4457-9151-5BCBB66D2456@sharp.fm> Message-ID: <046A17E9-9E8C-4C81-9EBA-D928D726DD72@sharp.fm> On 08 Apr 2025, at 10:28, Graham Leggett via rsync wrote: > Unfortunately all combinations of --fake-super that I have used so far have had the effect of backing up the backup, not restoring the backup. Looking in the source code, it looks like the difference between rsync performing a --fake-super backup, or rsync performing a --fake-super restore, is whether the rsync binary is running as root or not. https://github.com/RsyncProject/rsync/blob/9994933c8ccf7ead27c81fe4ce2eb4e08af20c7f/syscall.c#L119 This sort of makes sense when systems are working, but breaks down in a disaster recovery situation where a rescue disk is involved, and you're always root. In this case rsync is only able to backup, not restore. My next step is to try set up some users on the rescue environment and try fake a real system, and see if I can get this to work. Regards, Graham -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From minfrin at sharp.fm Tue Apr 8 11:54:24 2025 From: minfrin at sharp.fm (Graham Leggett) Date: Tue, 8 Apr 2025 12:54:24 +0100 Subject: rsync --chmod affects the source permissions as well as destination permissions Message-ID: Hi all, Another thing I've found is that my backups have lost their permissions. I misunderstood the --chmod option, thinking that it specified the permissions at the destination. What actually happens is that it overrides the source permissions, and has a side effect of the destination permissions being the same as the source. It looks like it works, when metadata is lost. I now need to fix this. What option will set the permissions on the destination side, while not affecting the permissions being fed into --fake-super on the source side? The end goal is a simple backup of a source filesystem preserving all users, all groups, all permissions, and all attributes, while the destination is a filesystem of a normal non-root user account. Regards, Graham -- From minfrin at sharp.fm Wed Apr 16 15:10:56 2025 From: minfrin at sharp.fm (Graham Leggett) Date: Wed, 16 Apr 2025 16:10:56 +0100 Subject: rsync --chmod affects the source permissions as well as destination permissions In-Reply-To: References: Message-ID: <98001141-3AF2-4A88-A2EF-A176E9AABFCA@sharp.fm> On 08 Apr 2025, at 12:54, Graham Leggett via rsync wrote: > Another thing I've found is that my backups have lost their permissions. > > I misunderstood the --chmod option, thinking that it specified the permissions at the destination. What actually happens is that it overrides the source permissions, and has a side effect of the destination permissions being the same as the source. It looks like it works, when metadata is lost. > > I now need to fix this. > > What option will set the permissions on the destination side, while not affecting the permissions being fed into --fake-super on the source side? > > The end goal is a simple backup of a source filesystem preserving all users, all groups, all permissions, and all attributes, while the destination is a filesystem of a normal non-root user account. I have proposed a --chmod-dest option to achieve this. The --chmod-dest option allows the destination permissions to be specified independently of the permissions backed up by --fake-super attributes. This means the source permissions are maintained, while on the backup machine permissions can be granted to allow specific users/groups to have read access to the backups. https://github.com/RsyncProject/rsync/pull/751 Regards, Graham -- -------------- next part -------------- An HTML attachment was scrubbed... URL: