Dan D Niles writes:
Craig Barratt writes:
What file system are you extracting the files onto? For example,
mknod probably doesn't work over NFS.
It is a FreeBSD FFS, which I believe is UFS under the hood.
Second, please browse the backup in BackupPC and compare the device
type, and major/minor device numbers with the actual devices. Do
they match? You can see the major/minor device numbers by downloading
the file in the browser and looking at the file's contents.
No, they do not match. For one particular file, the actual numbers are
69,0 while the numbers in the file are 70656,0.
If they don't match then there is some problem with the backup.
Otherwise, it means the backup is correct and there is some problem
instead when tar extracts the output from BackupPC_tarCreate.
In the latter case, what happens when you run
/path/to/BackupPC_tarCreate -h HOST -n -1 -s / /dev | tar -tvf -
Does the output match the real /dev?
For the same file, tar -tvf - reports 0,18087936.
I believe there is some problem with the way Solaris represents
devices versus the way FreeBSD does. When I use rsync by hand, and do
an ls -l of the file I end up with 0,0x01140000 instead of 69,0.
However, when I transfer it back with rsync by hand, it ends up being
69,0 as it should. Note that 0x01140000 is the same as 18087936.
Rsync is correctly dealing with the different representations of
device files. It seems like BackupPC_tarCreate needs to be aware of
what OS the client host is so that it can translate the device files
before creating the tar file.
I have tracked down this bug. Solaris uses 18 bits for the minor
device number, whereas most *nix systems use 8 bits. This shouldn't
matter if you only use the same XferMethod (eg: rsync or tar) for both
backup and restore.
But when you mix the two (eg: rsync for backup and tar for restore),
BackupPC has to extract the major and minor device numbers for
the tar file from the single value delivered by rsync. It assumes
an 8 bit minor device number, which isn't right for Solaris.
The solution is that protocol version 28 in rsync (2.6.2) now sends
separate major and minor device numbers, correctly extracted based on
the client's implementation. However, File::RsyncP still only uses
protocol version 26. So when I get around to upgrading File::RsyncP
to support protocol version 28 this problem will be fixed.
Craig
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
