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

2013-03-20 Thread Holger Parplies
Hi,

backu...@kosowsky.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 

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

2013-03-20 Thread Holger Parplies
Hi,

Phil Kennedy wrote on 2013-03-20 21:28:52 -0400 [Re: [BackupPC-users] Stop 
TrachClean / Return directories backup list]:
> On 3/20/2013 9:12 PM, Holger Parplies wrote:
> > [...]
> That's very odd, but a possiblity. My thought was that the mdadm.conf 
> was rebuilt when the Promise array was brought online, and the previous 
> admin simply omitted the old RAID confs for sda and sdb. From that point 
> on, sda booted as a normal drive rather than a RAID member and no one 
> was the wiser.

I'm not sure under which conditions the kernel automatically assembles an
array. Concerning the root FS, the kernel command line parameter should give a
reasonable hint. It's either 'root=/dev/md0' (or similar), then booting should
fail if it's not (and can't be) assembled, or it's 'root=/dev/sda1', which
should be a problem even *if* the array is assembled :-).

> As an aside, i've seen drives in other backuppc / software RAID 
> instances fail for no good reason, to the point that they pass long 
> smartctl test, yet mdadm is still convinced that the drive is bad. 
> Perhaps the vibration issue you've described was the culprit then?

In my case, I could simply re-add the device to the array. It wouldn't be
re-added automatically in any case.

> > Do the *hosts* show up in the web interface? If not, look at your hosts file
> > (/etc/BackupPC/hosts or something like that). If so, it could be
> They do now. One of the first things I did was to rebuild the hosts file 
> based on the information in /backup/pc.

What I meant is: were you describing an *empty* host page (i.e. host page with
no backups) or a *missing* host page (i.e. host unknown to BackupPC)?

> > That should be unnecessary as long as BackupPC is not running. Err, does the
> > web interface work without a running BackupPC daemon?
> 
> No, backuppc doesn't work without the daemon running.

That's funny. I consider "BackupPC" to be the daemon, not the web interface :-).

> The web interface 
> makes troubleshooting at little easier for me, especially since I have a 
> number of hosts to verify.

Yes, I can see that. I wouldn't want to interpret backup data from the command
line either.

> I can change the config files from terminal, but the web just makes it far
> prettier / simpler.

The thing is, it needs to work. Perhaps the daemon's understanding of which
backups exist and which don't is just fine (*), and it's only the web interface
that has problems. Either a problem with BackupPC or with the web interface
would cause the web interface to fail, so you need to fix both at once, rather
than one at a time. Ideally, one of us would write "BackupPC_ls" for you, so
you could list hosts and backups from the command line. Jeffrey, are there any
volunteers? ;-)
Actually, I seem to have written something vaguely similar in 2007 ... a quick
hack it was then, and it still is now, and it's almost certainly untested with
BackupPC 3.x, but you could give it a try. Should list the hosts and backups
BackupPC is aware of. Seems non-destructive enough, in any case.

Regards,
Holger

(*) Actually, the daemon doesn't care about existing backups; I should
probably write BackupPC::Lib instead. The web interface uses that, too,
but there's additionally the issue of the correct UID and perhaps
SELinux implications.
#!/usr/bin/perl --  -*- quick-hack -*-
#
# generate CSV output (actually, I'll use "|" as separator) for something
# like:
# hostname|date/time|size in MB|level|duration(min)
# almost as requested by John Rouillard.
# You might also want the backup number. See the comment below.

use lib '/usr/share/backuppc/lib'; # change to match your installation
use BackupPC::Lib;
use POSIX;

my $bpc = new BackupPC::Lib ('', '', '', 0)
  or die "Can't create BackupPC object!\n";
my @hosts; # array of hosts
my $hostinfo;  # pointer to hash of per host information
my @backups;   # info on all backups of one host
my $dt;# output fields for loop iteration: date/time
my $size;  # ... size
my $level; # ... level
my $duration;  # ... duration in minutes

$hostinfo = $bpc->HostInfoRead ();
@hosts = sort keys %$hostinfo;
# print 'hosts =>', (join '<, >', @hosts), "<=\n";

host:
foreach my $host (@hosts) {
  @backups = $bpc -> BackupInfoRead ($host)
or warn "Invalid hostname '$host' or other error!\n";
  foreach my $backup (@backups ) {
#  [-1]   <- add that in the line above for only
#the most recent backup of each host
# exploring the data structure:
# print "$host=>", join (',', map { "$_=$backup->{$_}" } sort keys %$backup), "<=\n";
$dt   = POSIX::strftime ('%Y-%m-%d %H:%M',
 localtime $backup -> {startTime});
$size = int ($backup -> {size} / 1024 / 1024 + 0.5); # MB, rounded
$level= $backup -> {level

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

2013-03-20 Thread backuppc
Holger Parplies wrote at about 03:50:34 +0100 on Thursday, March 21, 2013:
 > Ideally, one of us would write "BackupPC_ls" for you, so
 > you could list hosts and backups from the command line. Jeffrey, are there 
 > any
 > volunteers? ;-)
 > Actually, I seem to have written something vaguely similar in 2007 ... a 
 > quick
 > hack it was then, and it still is now, and it's almost certainly untested 
 > with
 > BackupPC 3.x, but you could give it a try. Should list the hosts and backups
 > BackupPC is aware of. Seems non-destructive enough, in any case.

I tend to just manually 'read' the 'backups' file for each
host... it's plaintext with tab separated values... and I pretty much
know what fields I am interested in... (alternatively, I just look at
the subdirectories that are numerical if I just want to know what
backups I have)... so who needs anything fancy? :P

--
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@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/