Hello Fabio Muzzi:
On Fri, Jun 20, 2014 at 12:32:54AM +0200, Fabio Muzzi wrote:
> I went to the web interface, browsed the backups, found that the
> directory I wanted to restore seemed to exist in the latest backup (it
> does not, in fact, but more on this later) and so selected the checkbox
> for it, and went on to restore it.
>
> I don' know why, but the directory did NOT exist in that backup, but
> only in the previous one. I still don't understand how can it be that
> the web interface shows it also in the latest backup, but this is not
> the real issue.
>
> Here is the log of the failed restore:
>
> ====================================================================
> Running: /usr/bin/env LC_ALL=C /usr/bin/sudo /bin/tar -x -p
> --numeric-owner --same-owner -v -f - -C /
> Running: /usr/share/backuppc/bin/BackupPC_tarCreate -h localhost -n 1391
> -s / -t -r /var/vmail/geldue.it/valentina.tomba -p
> /var/vmail/geldue.it/valentina.tomba/
> /var/vmail/geldue.it/valentina.tomba/.AAA\ -Spedizionieri.schenker
> Xfer PIDs are now 7844,7845
> ./
> tarCreate: Done: 0 files, 0 bytes, 1 dirs, 0 specials, 0 errors
> =====================================================================
>
> And here is the content of the generated tar file, that got restored by
> tar (I have run the same command by hand and redirected its output to a
> test file to get this output).
>
> ======================================================================
> $ tar tvf test.tar
> drwx------ mail/mail 0 2014-06-12 16:43 ./
> ======================================================================
That seems perfectly reasonable if the directory was empty at the time
that backuppc did it's last run.
> As you can see, instead of the expected directory (and files), owned in
> fact by mail.mail, all I got was "./" owned by mail.mail and with mode 0700.
> [...]
> Here we've got 2 issues: the first is an error in some index that shows
> a directory in backup 1391, while that directory is in fact in backup
> 1390 only. The second is that by restoring such directory from backup
> 1391 generates that damaging tar file, instead of an error and no output
> file as it should. (restoring from 1390 generates a proper tar file).
>
> I believe that BackupPC_tarCreate should absolutely be failsafe, and
> should NOT generate a tar file when it cannot find the data that I ask
> it to extract, instead of generating such a wrong tar file.
I have a couple of questions.
Is that directory a mount point that was unmounted when backuppc did
it's backup?
Is it possible that directory was empty when backuppc did it's
backup?
That is: does BackupPC has a good backup of that directory, it was just
an empty directory?
You said that directory was shown in the web interface for backup
1319, did the web interface show files underneath that directory in
backup 1391?
If there were no files under that directory in backup 1391 then it is
perfectly reasonable to get a tar ball with just the empty directory.
I am not sure if setting:
$Conf{BackupZeroFilesIsFatal} = 1;
would help or not (it depends on how you are backing up the
directory), but check backuppc's config.pl or the documentation for
details.
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
