Hi,
Fabio Muzzi wrote on 2014-06-20 00:32:54 +0200 [[BackupPC-users] A restore
issue creates a tar file that can damage the system]:
> I have experienced an issue while restoring a directory with backuppc
> version 3.1.0 from Debian. I know that it's an old version, but I have
> not been able to find anything about this issue, so I suppose it exists
> also in newer versions.
either that, or it does not exist at all.
> [...]
> I was trying to restore a local directory using a restore in place on
> the system itself.
I would not recommend that in any case. An in-place restore on a live system
has the potential to replace up-to-date not backed up data with outdated data
- due to human error on the part of the operator initiating the restore, the
admin that has configured the restore command, or the implementor of the
backup software. In addition to that, it might allow symlink attacks.
"In-place" restore is good if you want to populate the file system of a
replacement host or a replacement disk, where you have no data to begin with.
For a live system, I'd recommend a restore to a different directory. After
verifying the contents, you can rename the directories to swap contents (and
keep the pre-restore contents until you are satisfied everything is ok).
But that's just my opinion, and it probably wouldn't have prevented what
happened to you.
> 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.
No, it's a well documented feature. BackupPC shows you what it considers the
state of your backup set at the time of the backup (meaning that for your
incremental tar backups, tar will have missed file deletions, so BackupPC will
presume the files are still present and unchanged). Effectively, BackupPC will
"fill in" files unchanged in incremental backups from the reference backup,
usually the preceding full backup. This is true for browsing in the web
interface and for restoring via the web interface or the command line.
That means, the directory *did* exist in that backup, but it was unchanged
since the previous one - presuming your backup was an incremental and the
previous was a full.
If you don't understand this feature, you should be careful about configuring
and doing restores.
> The real issue is that the backuppc_tarCreate command issued from the
> web interface, not finding the directory I wanted to restore, generated
> a tar file that contains something very wrong, while it sould have
> simply failed with an error.
Should it? I don't believe 'tar' will fail with a fatal error if you tell it
to extract some files from a .tar, and not all of the files exist. In your
context, it might make sense. If you can select something in the web
interface, and it turns out not to exist in the file system, then that's
unexpected. Actually, BackupPC_tarCreate *does* fail with an error if
*nothing* was found, but your summary shows '1 dirs, ... 0 errors'.
As for the tar file generated, a single '.' entry doesn't tell much about what
it is supposed to represent. The root directory owned by mail/mail doesn't
make any sense, but for your target directory (or its parent directory), it
does. So either there's a bug in BackupPC_tarCreate, or in its invocation,
or somewhere on your system.
> [...]
> 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
That quoted space looks suspicious, but I'd need to look closer at the code to
say what was actually executed.
> [...]
> 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.
>
> Restoring that tar on the system made the root directory owned by
> mail.mail and with 0700 permission, which is WAY TOO WRONG.
That is why you don't automatically feed unchecked input to
'sudo tar x -C /'. Thank you for proving my point.
> I lost one hour trying to understand what happened to the server, and
> another one trying to reproduce the error, which I did.
Don't ask me how many hours I've "lost" on this mailing list.
> Here we've got 2 issues:
Up to that point, I agree.
> 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.
Well, you haven't provided any detail or proof, so we'll assume it's an error
on your part or in your system (interpretation, configuration, file system
corrup