Backup Central

Solaris requires the files in /devices when doing a bare metal
restore. Copying /devices from another Solaris machine does not
always work. Therefore, backups of /devices are needed.

I am using the rsync backup method using BackupPC 2.1.0beta2pl1 with
RsyncP version 0.52 on a FreeBSD server. The client is a Solaris 8
box running rsync 2.6.2.

It acts like it is backing up device in /devices, but when I create a
tar archive and try to extrac the devices I get:

...
tar: ./devices/sbus < at > 1f,0/sbusmem < at > 2,0:slot2: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > 3,0:slot3: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > d,0:slotd: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > e,0:slote: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > f,0:slotf: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/zs < at > f,1100000:a: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/zs < at > f,1100000:a,cu: mknod failed: Invalid argument
...

for every device file. I know that tar can handle devices, so I am
assuming that there is something wrong with either the way BackupPC is
saving the device files or the way it is adding them to the tar file.

If someone could point me in the right direction, I will try to track
this down.

Thank,

Dan


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Dan D Niles writes:

Solaris requires the files in /devices when doing a bare metal
restore. Copying /devices from another Solaris machine does not
always work. Therefore, backups of /devices are needed.

I am using the rsync backup method using BackupPC 2.1.0beta2pl1 with
RsyncP version 0.52 on a FreeBSD server. The client is a Solaris 8
box running rsync 2.6.2.

It acts like it is backing up device in /devices, but when I create a
tar archive and try to extrac the devices I get:

...
tar: ./devices/sbus < at > 1f,0/sbusmem < at > 2,0:slot2: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > 3,0:slot3: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > d,0:slotd: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > e,0:slote: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/sbusmem < at > f,0:slotf: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/zs < at > f,1100000:a: mknod failed: Invalid argument
tar: ./devices/sbus < at > 1f,0/zs < at > f,1100000:a,cu: mknod failed: Invalid argument
...

for every device file. I know that tar can handle devices, so I am
assuming that there is something wrong with either the way BackupPC is
saving the device files or the way it is adding them to the tar file.

If someone could point me in the right direction, I will try to track
this down.

What file system are you extracting the files onto? For example,
mknod probably doesn't work over NFS.

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.

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?

Craig


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

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.

Dan