BackupPC-users

Re: [BackupPC-users] Switching backup methods

2009-09-29 10:47:41
Subject: Re: [BackupPC-users] Switching backup methods
From: "Jeffrey J. Kosowsky" <backuppc AT kosowsky DOT org>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Tue, 29 Sep 2009 10:41:58 -0400
Holger Parplies wrote at about 13:45:34 +0200 on Tuesday, September 29, 2009:
 > Hi,
 > 
 > Jeffrey J. Kosowsky wrote on 2009-09-29 02:49:11 -0400 [Re: [BackupPC-users] 
 > Switching backup methods]:
 > > Holger Parplies wrote at about 15:54:25 +0200 on Saturday, September 26, 
 > > 2009:
 > >  > [...]
 > >  > 3. I believe I recall reading that *restoring* a backup *made with 
 > > rsync*
 > >  >    with the tar XferMethod produces warnings (or errors?) - probably
 > >  >    because tar doesn't understand the "deleted file" entries in the
 > >  >    attrib files. [...]
 > > 
 > > If I am understanding you correctly, then presumably this problem
 > > would only occur for incremental backups and not for full backups
 > > since the concept of "deleted file" shouldn't exist in a full backup.
 > 
 > I agree on that, but I have never experienced the problem myself, just read
 > about it one or two times over the last years. At the time, I wasn't familiar
 > with the attrib file contents. Now, it makes sense that this problem could
 > occur. But I might be mistaking things. The important part is that if you run
 > into problems when restoring after changing the XferMethod, changing it back
 > for the restore might help.
 > 
 > > Second, how do tar incrementals signal deleted files if they don't use
 > > the "deleted file type" (10) attribute?
 > 
 > They don't. tar can't detect deleted files. Deleting a file doesn't change 
 > its
 > modification time, it deletes it ;-).
 > 
 > > I have never used tar as a XferMethod before so I don't understand how it
 > > works differently from rsync here...
 > 
 > Well, you don't have fileLists ... a full tar backup is just a tar stream of
 > all the files on the sender side, which is then interpreted by BackupPC and
 > integrated into the pool. An incremental tar backup is a tar stream of all
 > the files on the sender side that have changed since a timestamp. Files not
 > present are either unchanged or deleted (or moved to a new location). There's
 > no way to tell which.
 > 
 > Regards,
 > Holger
 > 

Maybe this is offtopic, but wouldn't it be helpful to have something
like a Tar+ Xfer incremental method that would make up for tar's
deficiencies.

For example if you ran a "find" on the share and combined that with
the tar data then presumably you would be able to identify which files
have been moved or deleted (vs. which ones are unchanged). This would
(in general) not be too intensive either computationally or from a
bandwidth perspective and would allow Tar incrementals to be "correct"
(of course it still wouldn't detect files that changed but had an
earlier timestamp but generally that is a less frequent case).

Of course if you go too far down this path, you might end up rewriting
rsync, but at least there might be some low hanging fruit that would
improve the tar method for incrementals.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
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/