On 12/05/2012 10:18 AM, Les Mikesell wrote:
> On Wed, Dec 5, 2012 at 12:57 AM, Gary Roach<gary719_list1@...> wrote:
>
>>> While this should work, I'm curious why you don't use rsync over ssh
>>> which would be more typical for Linux.
>>>
>>>
>>>
>> It's a small personal network, inside a firewall and with nothing of a
>> sensitive nature. My wife and I are the only users. SSH needs to have
>> keys transfered about. I didn't want to bother.
>>
>>
> Maybe it's just from having done it many times, but it seems to me
> like less bother to do an ssh-keygen once on the backuppc box and an
> ssh-copy-id once for each target host than to set up inetd and an
> rsynd config on each target.
>
>
Les, thanks for your help. As for as the ssh goes, I had some trouble
with permissions in the past and rsync slid right in with a minimum of
fuss. It's done. It works.
I finally restored each main directory separately. This worked with
everything except the 19.8 GB /home directory. I finally saved that one
to a tar file an sneekernetted it over to the macine being backed up.
This worked.I'm not sure what happened the first time I tried this.
Maybe it's because I now have the -D switch set in inetd.conf. Or maybe
the second time is the charm. I still have some minor problems but they
are Debian problems that have nothing to do with backuppc. Once I get
those straightened out I plan on doing a full backup and then try to do
a full restore. I guess this was "just another f*****g learning
experience". Wish me luck.
Again, thanks for the help.
Gary R.
Gary R.

backuppc@... wrote:
> Matthias Meyer wrote at about 08:41:34 +0100 on Monday, December 3, 2012:
> > Wow - thank you for details :)
> >
> > Most of the files found are realy top level attrib files.
> > But BackupPC_verifyPool.pl some files found like
> > [1459587] fXLC_LOCALE ( 979) !=
> > [c5e2162bfb3286475d4b71503593ffcd
> > [1459783] attrib ( 73) !=
> > [42d8ce042b950daa935fe4e0440d2020
> > too.
> >
> > Anyone have an Idea whats happen here?
> > Should I simply rename those files as "suggested"?
> As mentioned in Holger's and my replies, I would do the following:
>
> 1. Check to see you have the latest version of BackupPC and check the
> changelogs to verify that the error has been corrected.
I'm running BackupPC V3.1
"Unfortunately" I've running a patched version ;) to make yearly backups
and do not remove partial backups until a successfull backup is finished.
So, maybee, it is my fault but I didn't believe that ;)
>
> 2. Look up the thread I referenced so you can understand what is going
> on with the top level attribs.
I've read it. Thanks :) I've a lot of PCs with more than one share.
Blessedly - it isn't a real problem :)
>
> 3. Give some more information about the files that are not top-level
> attribs so that we can try to understand what is going on. What is
> the content? what are their real names? (search the pc-tree) What
> types of files? etc. etc. Look for patterns.
I make a regulary backup of my backuppc data with rsync to another device.
The analyzing performs on this backup-device.
3010068 files in 4096 directories checked, 3538 had wrong digests, of these 2 zero-length.
Allways most of the 3538 files I'm found in /var/lib/backuppc/pc and they can be simply renamed.
But some files seems to have special problems.
e.g. of files with wrong MD5-names as well as my analyzis (so far):
1) I can't find the inode in /var/lib/backuppc/pc. I would believe BackupPC_nightly will remove this file
144312220 -rw-r----- 2 backuppc backuppc 3976 20. Dez 2009 /var/lib/backuppc/cpool/0/0/7/00754a6772b82e796d3cc12ac84661~0
2) Hardlink-refCount seems to be wrong. How to correct it? e2fsck doesn't do this job.
157158688 -rw-r----- 3 backuppc backuppc 346 20. Dez 2009 /var/lib/backuppc/cpool/0/0/3/0035b696f4c9aa129dd310fbac63db~0
157158688: (3) 4kB 20.Dez.2009 /var/lib/backuppc/pc/vdr/245/f%2f/fusr/fshare/fdoc/fdefoma/fcopyright
3) the name in cpool isn't a MD5
a) In which case this can be happen? If BackupPC_link has been interrupted?
b) realy a Hardlink-refCount of 10003? The backuppc status page say: "Pool hashing gives 3474 repeated files with longest chain 31,"
152963304 -rw-r----- 10003 backuppc backuppc 86 13. Dez 2011 /var/lib/backuppc/cpool/0/1/4/fcommon
152963304: (10003) 4kB 13.Dez.2011 /var/lib/backuppc/pc/vdr/645/froot/fusr/fshare/fdoc/fkde/fHTML/fda/fkleopatra/fcommon
152963304: (10003) 4kB 13.Dez.2011 /var/lib/backuppc/pc/vdr/645/froot/fusr/fshare/fdoc/fkde/fHTML/fda/fkwatchgnupg/fcommon
152963304: (10003) 4kB 13.Dez.2011 /var/lib/backuppc/pc/vdr/645/froot/fusr/fshare/fdoc/fkde/fHTML/fda/fknode/fcommon
152963304: (10003) 4kB 13.Dez.2011 /var/lib/backuppc/pc/vdr/645/froot/fusr/fshare/fdoc/fkde/fHTML/fda/fkjots/fcommon
152963304: (10003) 4kB 13.Dez.2011 /var/lib/backuppc/pc/vdr/645/froot/fusr/fshare/fdoc/fkde/fHTML/fda/fkorganizer/fcommon
4) another example of wrong Hardlink-refCount together with wrong MD5 filename
62523004 -rw-r----- 9 backuppc backuppc 12662 14. Dez 2009 /var/lib/backuppc/cpool/0/2/2/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vdr/406/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vdr/415/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vdr/245/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vdr/381/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vdr/443/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vdr/440/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
62523004: (9) 16kB 14.Dez.2009 /var/lib/backuppc/pc/vhost/427/f%2f/fusr/fshare/flocale/fid/fLC_MESSAGES/fshadow.mo
>
> 4. As Holger mentioned, there is no harm not renaming other than
> wasted pool space (which is typically quite small for attrib files)
> and the inelegance of having wrong md5sum file names. Otherwise,
> you can use my routine to fix them automatically or you can write
> your own or do it manually.
I will use your script. But first I'ld like to understand what's happend :)
Also interesting. All files from 2012, found by Holgers script, are top level attrib files.
The strange things only happens with older files.
--
Don't Panic