Comment 4 for bug 67497

I think I have reproduced the behaviour again on BackupPC 3.0.0-4ubuntu1 on Ubuntu 8.04.3

Following the description:

Results are

/etc/
Backed up where permissions are liberal enough to allow reading the files

The fstab for example has
 -rw-r--r-- 1 root root

Enough for tar to read it. Restores Fail. BackupPC reports this.

The shadow file for example - fails to get backed up entirely and does not even show up in the browse backups area even as an empty file.
-rw-r----- 1 root shadow

/home has the same type of behaviour. Only by how liberal the default umask is, are users home directories able to be backed up. Tied down permissions will result in missing files with no errors reported.

For my user mwalker a good example of this is that my .ssh folder does not feature in the Backups. But everything else with liberal perms does.

Failure does not result and the Backup does not stop. So BackupPC claims success even when some of the files fail to be read.

The only warning sign you get is in the log file one of the lines says:
2009-11-09 14:53:50 full backup 0 complete, 2737 files, bytes, 29 xferErrs ( bad files, bad shares, 29 other)

but if the user sees no fail failures why would he have reason to view the logs.

So yes, the user could come to restore his files and find the ones he needs were never backed up. I am about to use it in production and managed to avoid exposure to this problem entirely by using sudo from the beginning.

Maybe its worth scripting part of the deb to add a few scripts restrictive tar and rsync with entries to be added to the sudoers file?

Im trying to reason this behaviours existence as to whether its a genuine bug or just needed to ignore not being able to backup super sensitive things or locked files - but hang on that would only be useful for Windows for which a tar backup would need additional setup anyway.

What do you think Ubuntu Bug guys?