I’ve noticed several issues or strange behavior when restoring files from “rsync” backups.
The problems occur almost identically on different machines.
A NethServer release 7.9.2009 (final) is used in each case
with kernel version 3.10.0-1160.53.1.el7.x86_64
SFTP/ rsync backup set up via “System / Backup”.
The SFTP user on the backup host has limited rights but full access to the backup directory.
The backups are running without errors, after several days only errors are displayed (Nethserver backup log via email) that files in the root user’s directory cannot be deleted/updated.
“rm: unable to remove '/mnt/usb_backup/zdvasrv_zdva_de/pushed_rsync/2022-02-04-023109/root/”$some_file_from_root"’: no permission"
This is the first suspected bug (but not the biggest problem).
Now a file should be restored from one of the regular rsync backups via “Applications / Restore data”. The corresponding backup configuration is selected under “Choose backup”. Only one backup is shown under “Choose date”, although a backup goes through every day (perhaps the second error).
This backup is selected and a file is searched for from a home directory using the search function. If the found file is marked and restored, the following happens:
If the restore is performed without checking the “overwrite” checkbox, the restored file (prefix .restore-datumsstring) is owned by the user and group “root”. File permissions are now “-rw-r–r–” instead of “-rwxrwx—” as before. There are no other abnormalities.
If the restore is carried out with a tick in the “overwrite” checkbox, the effects are completely different. The recovered file is owned by a user and group that does not exist on the system. Therefore, only the IDs are displayed. The IDs are identical to the SFTP user IDs on the backup host. It is interesting that the file restored in this way (overwritten) at least has the correct access rights “-rwxrwx—”.
However, the recovery problem does not only extend to the recovered file! Also, the entire home directory where the file was restored is now owned by the SFTP user and group, which does not exist on the system. As a result, the user can no longer access their own files.
An attempt with other files from file shares or e-mail folders was not carried out.
As i see now, the WHOLE folders in path to the user home folders ("/var/", “/var/lib/”, “/var/lib/nethserver”, “var/lib/nethserver/home/”) has wrong ownerships after restoring a single file from backup!!!
The problem first appeared on a machine that had previously had recovery issues.
On a completely different machine - different location, different network, different backup host but comparable target system and comparable restrictions of the SFTP user - the problems could be reproduced identically.
I hope my description was useful.