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
corruption, whatever).

> 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).

The tar file per se is not damaging. Extracting it to the root directory is.
As for whether the contents are incorrect for the supplied arguments, that
might be true. To reproduce it, we'd need to know something about the state
of your backups. The problem could be in a completely different place.

> 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.

If you feel so strongly about it, how about putting in just a minimal bit of
effort? You haven't really done anything so far. You haven't paid for the
software, or for the support. You've used it in a way that defies common
sense. Something stupid happened, and it's not really clear whether it's a
fault of the software or of your system. No lasting damage seems to have been
done (your MTA probably wasn't even affected), in any case no data was erased
or modified.

So, where's the bug report? Where's the analysis of what went wrong? Where's
the patch to fix it?

Regards,
Holger

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
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/