BackupPC-users

Re: [BackupPC-users] Stop TrachClean / Return directories backup list

2013-03-20 14:57:53
Subject: Re: [BackupPC-users] Stop TrachClean / Return directories backup list
From: Holger Parplies <wbppc AT parplies DOT de>
To: Phil Kennedy <Phillip.kennedy AT yankeeairmuseum DOT org>
Date: Wed, 20 Mar 2013 19:56:26 +0100
Hi,

Phil Kennedy wrote on 2013-03-20 12:37:10 -0400 [[BackupPC-users] Stop 
TrachClean / Return directories backup list]:
> Hi,
> I recently had a somewhat odd system failure (poorly configured software 
> RAID) that lead to a *very* old set of BackupPC config files being 
> loaded. On one windows machine (possibly more), the default SMB share 
> was reset to C$ instead of E$. The full count keep, plus the min keep 
> values were also set lower than we wanted them. BackupPC naturally 
> marked all the old E$ directories as trash, and has removed them from 
> the browse backup list.
> 
> The good news (besides the fact that the previous admin of this box is 
> several states away and out of arms reach....) is that the backup 
> directories and their data still exist under the 
> /var/lib/backuppc/pool/hostname/backup number/ directory.

You probably mean "pc", not "pool".

> They just don't show up when you browse the backups.

First of all, let's imagine what happens in the case you described.

1.) The backup definition (SmbShareName, BackupFilesOnly, BackupFilesExclude)
    is changed.
    => There should be no effect on existing backups. Future backups will be
       done according to the new definition. This will involve backing up the
       wrong data (meaning you get a somewhat bogus backup). tar/smb
       incrementals won't work well, because they use a reference date,
       meaning you only get files in the new set that were changed since the
       reference backup was done. rsync will tend to transfer large amounts
       of data. If you do a *full* backup with the changed definition
       and then change back to the correct definition, you will, again,
       transfer large amounts of data. IncrLevels may make that even more
       complicated.
       In any case, I would recommend forcing a full backup after changing
       back to the correct settings and not doing any backups with the
       incorrect settings if possible. See $Conf {BackupsDisable}, which should
       also avoid expiring backups.

2.) The history settings (FullKeepCnt, IncrKeepCnt, etc.) are changed.
    => On the next invocation of BackupPC_dump (with the correct options) for
       the host, normally on the next backup *attempt*, backups will be expired
       as defined by the new settings. This means that all backups no longer
       to be kept will be moved to $TopDir/trash. As I read the code, they
       will get a name consisting of time, process id, and counter. That means
       you will have a hard time identifying where they came from (because
       neither host name nor backup number will be visible any longer). The
       modification date of the subdirectories might give you a hint
       concerning the order they belong in. Note, though, that
       BackupPC_trashClean will become active by default every 5 minutes and
       delete everything in $TopDir/trash. You can increase the interval by
       setting $Conf {TrashCleanSleepSec}, but you should note that upon
       startup trashClean will empty the trash once before sleeping.
       You should be able to protect items already in the trash by setting
       permissions accordingly. trashClean just tries to unlink/rmdir the
       items, so if you 'chmod a= ...' a non-empty directory, it will simply
       fail and leave the directory where it is (for a file, this would
       obviously not work). Revoking write permission on $Topdir/trash itself
       should also stop trashClean, but I believe the code moving things there
       in the first place would then resort to deleting the trees instead.

> My question is two fold;
> 
> 1. How do I get the directories back in the list? (I'm assuming this 
> involves one of the .rrd files?) Again, the data *is* there, it's just 
> not web accessible.

No. The rrd-files are a Debian add-on, I believe. They don't influence
BackupPC operation at all. You might be looking for
'BackupPC_fixupBackupSummary'. Which version of BackupPC are you using (and,
for that matter, which Linux distribution)?
And which data is where? What you are describing does not seem to be
consistent with what should be happening. Can you confirm that under
/var/lib/backuppc/pc/* the <num> directories you are expecting are really
all still there?

> 2. How can I tell TrashClean to take a couple days vacation while I sort 
> out the consistency of other 130 machines?

Well, as I said, you could set $Conf {TrashCleanSleepSec} to a high value, but
the point really is that you want to avoid the backups being trashed in the
first place. What I'd probably do is stop BackupPC completely while I sort
things out. Presuming that is not possible, I'd set $Conf {BackupsDisable} = 2
in the main config.pl to disable all backups by default, and then re-enable
them one by one for each host I have checked and corrected in the host.pl file.
Note that I have not tested this. Perhaps someone could confirm that backups
are not expired for hosts with BackupsDisable'd ...

Regards,
Holger

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
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/