BackupPC-users

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

2013-03-20 17:27:37
Subject: Re: [BackupPC-users] Stop TrashClean / Return directories backup list
From: Holger Parplies <wbppc AT parplies DOT de>
To: backuppc AT kosowsky DOT org
Date: Wed, 20 Mar 2013 22:26:12 +0100
Hi,

backuppc AT kosowsky DOT org wrote on 2013-03-20 15:35:08 -0400 [Re: 
[BackupPC-users] Stop TrachClean / Return directories backup list]:
> Holger Parplies wrote at about 19:56:26 +0100 on Wednesday, March 20, 2013:
>  > [...]
>  >        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. 
> 
> You should be able to completely recreate the numbering plus the info
> in the 'backups' file using the backupInfo file.

presuming it's 3.x ... yes, I should have thought of that. I even mentioned
BackupPC_fixBackupSummary ...

Still, I would prefer not moving backups that are to be kept to the trash in
the first place :). If nothing else, it should avoid needing to reconstruct
the backups file.

I'd like to add that it might be hard to tell which backup (if any) trashClean 
might have started deleting. Backups will usually not be moved to the trash
unless there is a trashClean process running, after all.

>  >        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.
> 
> Yes - anything not moved will be deleted directly by RmTreeDefer

Which means you shouldn't do that. Change permissions on subdirectories of
trash/ (if you need to), not on the directory itself. Or see below.

>  > 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 ...
> 
> Note that BackupPC_dump code has the following
> usage comment:
> #     -e   Just do an dump expiry check for the client.  Don't do anything
> #          else.  This is used periodically by BackupPC to make sure that
> #          dhcp hosts have correctly expired old backups.  Without this,
             ^^^^^^^^^^
> #          dhcp hosts that are no longer on the network will not expire
> #          old backups.
> 
> So, expiry is still called even if Backups are disabled...

Yes, but only for DHCP hosts, I believe, and, as you say,

> the code for BackupPC_dump seems to exit before expiry if
> BackupsDisable == 2 so you should be ok...

The main config file contains the following comment explaining
$Conf{BackupsDisabled}:
# Disable all full and incremental backups.  These settings are
# useful for a client that is no longer being backed up
# (eg: a retired machine), but you wish to keep the last
# backups available for browsing or restoring to other machines.

It would make sense not to do expiry for retired machines. Still, I'd hate for
you to rely on our opinion and find your backups disappearing.

So, I'd probably set both BackupsDisabled *and* TrashCleanSleepSec - just in
case.

Jeffrey wrote on Wed, 20 Mar 2013 15:16:58 -0400:
> In fact, if /var/lib/backuppc/pool/hostname/backup number/ truly

Host names are still not pooled ;-).

> exist, then they should all show up in the browser, provided that the
> 'backups' file in each 'hostname' directory hasn't been
> corrupted.

Thank you for clarifying that. I meant to imply it, but I don't think I
actually said it.

> [...]
> So, I guess I'm not sure why they would still be in the pc tree but
> [not] browsable. Perhaps there is a permissions issue?

My first guess is that the observation is inaccurate. It *is* rather hard to
tell just from the backup numbers (unless, of course, your schedule said to
keep 100 backups and the incorrect one now limits it to 7).

Other than that - SELinux perhaps? What do you see in the browser, no backups
at all, or only a few backups?

You (Phil, that is) weren't explicit on the nature of the failure. I'm
guessing it affected your root FS (/etc/backuppc) and not your BackupPC pool
(/var/lib/backuppc) - is that correct?

> [...]
> If it's already in the trash... well you have to do something a little
> kludgey... I probably would just change the permissions on the trash
> directory so that user backuppc can't go there... or change the
> ownership of the subdirectories...

Sometimes it's even more simple, though I obviously missed it the first time
round, too:
% mkdir $TopDir/saved-from-trash
% mv $TopDir/trash/* $TopDir/saved-from-trash

(this should probably even stop an active trashClean from deleting (much) more
from what it's currently working on).

> Alternatively one could temporarily set BackuppPC_trashClean to
> /bin/true or something like that...

I was going to suggest something similar (adding 'exit 0;' near the top of the
script), but that would probably lead to BackupPC restarting it each time
round in Main_TryToRun_nightly. Not necessarily a problem, but unneccessary.
How about

# dpkg-divert --local --rename --divert 
/usr/share/backuppc/bin/BackupPC_dont_clean_the_trash 
/usr/share/backuppc/bin/BackupPC_trashClean
# cat <<EOF > /usr/share/backuppc/bin/BackupPC_trashClean
#!/usr/bin/perl
while (1) {
  sleep 86400;
}
EOF
# chmod a+x /usr/share/backuppc/bin/BackupPC_trashClean

That would even prevent a package upgrade from overwriting it :-). Just don't
forget to dpkg-divert --remove it once you're done.

Still, the most simple and robust course of action would be to just stop
BackupPC while you are fixing things (and perhaps stop it from automatically
starting on reboot).

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/