Claims success when backup fails

[Tero Karvinen]

Binary package hint: backuppc

Backuppc claims that backup has succeeded when it has failed. This can happen when backup fails because of permissions.

1) Add a directory where user 'backuppc' does not have a read permission. /home/ could be a very common example.
$ sudo nano /etc/backuppc/localhost.pl
  # commented out: $Conf{TarShareName} = ['/etc'];
  $Conf{BackupFilesOnly} = ['/etc/', '/home/'];
$ sudo /etc/init.d/backuppc restart
2) Run full backup
- http://localhost/backuppc : Host summary: localhost: Start Full Backup

What should happen: An error about failed backup should be given, with explanation and instructions how to fix it. Host status should be failed.

What happens (the bug): Backup seems to run normally. When refreshing after about a minute, a new backup is listed for browsing under "Backup Summary". "Host summary" shows green (good) status: "backup done". Host is listed under "Host summary: Hosts with good Backups".

This bug can lead to data loss. User could pick a wrong directory (eg. /etc/) for verifying the backup, thinking it works. When disks break, user is not happy to see that backup has failed. Usually, the most important data (eg. /home/) is not included.

Bug was found on Ubuntu 6.06 LTS Dapper (grep DESC /etc/lsb-release), apache2 2.0.55-4ubuntu2.1, backuppc 2.1.2-2ubuntu5 (dpkg --list backuppc apache2).

[Matthew Woerly (nattgew)]

Thank you for your report. I apologize that no one has gotten back to you about this yet.
Does this still happen?

[Tero Karvinen (karvinen+launchpad)]

I chose a different backup software and don't have backuppc installed at the moment. Unfortunately, I don't have time to test this anytime soon.

[Matthew Woerly (nattgew)]

Thanks, I'll change it to Invalid. If you find some time to test and find that this is still a problem you can reopen it.

[Mark Walker (cypher-ciscosystems)]

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?

[Mark Walker (cypher-ciscosystems)]

Edit: Of course the important line in the log file extract is "29 xferErrs"