Re: Backups to USB disk with Dump/Restore? (restore seems to hang)


Tried seemingly everything now - no change

This is what I did:

reformat my USB disk with ext2 filesystem
boot into systemrescuecd
mount logical volume groups read-only, mounted usb drive
did the dump to the usb drive - LOTS of messages about ACL properties
not being backed up (I think this has to do with SELinux related stuff
on FC4) - 60GB file created
rebooted, repeated the restore procedure - same thing, hangs on
"extract".

Maybe incompatible versions of dump and restore? (dump from the live
CD, restore from FC4).

I'll try the restore offline (ie from the live CD)


rcress@xxxxxxxxxx wrote:

Thanks Jerry - good to know I'm not doing something that is never going
to work!

I've managed to get to a point where I can mount the root filesystem
readonly - hopefully a full backup with dump will now be restorable. If
it doesn't work I'll follow your suggestion and format the drive and
dump to a file (might do that anyway - but I'd like to see if this way
works too).

FYI - this is what I've done (useful info here for future reference
folks!)

Boot into "systemrescuecd" (www.sysresccd.org). The following steps are
needed to activate the logical volumes that Fedora Core creates:

vgchange -a y (change attributes to activate all logical volumes)
vgmknodes (make dev files)

now can mount the drive readonly. I'll let you know if dump/restore now
works :)

Ron

Jerry Peters wrote:

rcress@xxxxxxxxxx wrote:

More Info:

If I ctrl-C I get back to the restore prompt. An ls shows the file
still marked for extraction. If I repeat the extract command, this time
I get

Specify next volume # (none if no more volumes): 1
Mount tape volume 1
Enter ``none'' if there are no more tapes
otherwise enter tape name (default: /dev/sdb1)
Input block size is 32
resync restore, skipped 1028 blocks

It recreates the directory structure (under my pwd) but doesn't restore
any files. I'm guessing the backup is corrupt because the filesystem
was mounted rw when I did the backup, even though I was in single use
mode. Sound correct? Am I rooted? Time to create a fresh full backup?

Anyone know how I can drop to single user mode and remount my *root*
partition read-only and still be able to run commands?


rcress@xxxxxxxxxx wrote:

Extra info:

If the pid of the restore command is 8722, then is I cat
/proc/8722/status I see:
Name: restore
State: D (disk sleep)

Is this a clue?? :)


rcress@xxxxxxxxxx wrote:

Hi folks,

Anyone know if there are any known problems using an external USB hard
drive to backup a system using "dump" and restoring it later using
"restore"?

I've recently plugged in a Lacie "red brick" 500GB hard drive and done
a complete dump of my hard drive to it using "dump". That *seemed* to
work and when I go into the archive interactively I can navigate around
and see the files, but after I add them and use the command "extract"
it seems to sit there doing nothing and I don't know where it is trying
to put the files, or if I've just done it wrong.

The system is Fedora Core 4. When the Lacie brick was first attached
the system created a mount point for it. I used the following command
from single user mode to dump the filesystem:

dump -0u -f /dev/sdb1 /

and the file /etc/dumpdates shows that the dump occured last Thursday.
It dumped about 70GB to the drive.

Now if I put the USB drive into another machine (a Windows machine for
instance) it thinks it's unformatted, and Fedora no longer creates a
mount point for it (all consistent with my writing directly to it I
suppose).

My restore session looks like this:

[root@cfd1 ~]# restore -i -f /dev/sdb1
restore > pwd
/
restore > cd /etc/X11
restore > ls xorg*
xorg.conf
xorg.conf.backup
xorg.conf.twinview
restore > add xorg.conf
restore > ls xorg*
*xorg.conf
xorg.conf.backup
xorg.conf.twinview
restore > extract
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume # (none if no more volumes): 1

And at this point it just seems to sit there, with restore using about
0.7% cpu and usb-storage using about 1%. Any thoughts?

Thanks in advance,

Ron

restore >


I've been using dump/restore to an external USB disk with no problems,
used dump then restore several times when repartitioning hard drives
and migrating systems to different machines. Also I periodically
re-create my alternate root partition from a dump image. I normally
dump mounted partitions. My suggestion would be to get the source for
dump/restore from sourceforge and build your own.

I just noticed that you're using the device as a backup medium, I've
never tried that except for tape, why not format sdb1 as ext2 and
dump to a file?

Jerry

.

Relevant Pages

  • Re: DFSMSdss Data Loss Exposure (UPDATE)
    ... PATCH BYTE FOR DS1DSCHA / DS1IND20 ON FULL AND TRACKS RESTORE ... TRACKS RESTORE when DFSMSdss is not invoked via the API. ... This future enhancement would possibly include a change in default RESTORE behavior based on use of "RESET" in DUMP, with a new RESTORE option to allow for overriding default behavior. ... The crux of the problem is that the only practical way to make a physical copy of a volume with DFSMSdss for moving the volume or recovering it elsewhere is with "DUMP FULL" physical dump, and if this is recovered to another device with the obvious counterpart "RESTORE FULL", the result is currently not an identical volume, but a volume with all the VTOC "changed" bits on the volume reset. ...
    (bit.listserv.ibm-main)
  • DFSMSdss Data Loss Exposure (Was Re: DFSMSdss DOC APAR OA20117)
    ... which is the default usage, indicating the dump is not intended as a replacement for individual dataset dumps -- to save the image of a DASD volume and expecting at some point to use this dump with a "RESTORE FULL" to move the volume to another DASD drive, as part of a Data Center move or migration to new equipment, or for Data Center recovery at a remote site, THEN MOST LIKELY YOU ARE CURRENTLY EXPOSED TO SOME FORM OF DATA-LOSS! ... The crux of the problem is that the only practical way to make a physical copy of a volume with DFSMSdss for moving the volume or recovering it elsewhere is with "DUMP FULL" physical dump, and if this is recovered to another device with the obvious counterpart "RESTORE FULL", the result is currently not an identical volume, but a volume with all the VTOC "changed" bits on the volume reset. ...
    (bit.listserv.ibm-main)
  • Re: Backups to USB disk with Dump/Restore? (restore seems to hang)
    ... I've managed to get to a point where I can mount the root filesystem ... readonly - hopefully a full backup with dump will now be restorable. ... If I ctrl-C I get back to the restore prompt. ... used dump then restore several times when repartitioning hard drives ...
    (comp.os.linux.hardware)
  • Re: DFSMSdss Data Loss Exposure (UPDATE)
    ... APAR OA20907 was opened by IBM to provide a temporary fix to the DFSMSdss RESTORE problem in the form of ADRDSSU patch byte that can be set by an installation or on a specific invocation of ADRDSSU to inhibit the reset of the DS1DSCHA bit on "RESTORE FULL" or "RESTORE TRACKS". ... This future enhancement would possibly include a change in default RESTORE behavior based on use of "RESET" in DUMP, with a new RESTORE option to allow for overriding default behavior. ... The crux of the problem is that the only practical way to make a physical copy of a volume with DFSMSdss for moving the volume or recovering it elsewhere is with "DUMP FULL" physical dump, and if this is recovered to another device with the obvious counterpart "RESTORE FULL", the result is currently not an identical volume, but a volume with all the VTOC "changed" bits on the volume reset. ...
    (bit.listserv.ibm-main)
  • Re: dump/restore dont work, handbook lies
    ... this all on a 7.0 freebsd system. ... Did you mount the large USB file system to /mnt? ... Otherwise it wrote the dump to /mnt on the old disk which you wiped. ... Try looking at that dump file on the USB unit using 'restore -vf' ...
    (freebsd-questions)