Approx dump restore time

J

jaymax

I do not expect an exact or precise answer here, given all the subjective & dependent parameters.

Just a rough ballpark approximation, what time frame should a restore occur in?

param :-
an ~1Ghz system, running 6.x O/S, dumpfile ~ 30 Gb, UFS2 file systems w/ default blocksize, target directory 400 Gb w/ > 190 Gb free capacity, minimal use system booted from Fixit. I do not have the actual write speed of the disk but would expect it to be that of a normal IDE drive 4/500 Gb

I am into my 56+ hr of a restore of a 29Gb dumpfile and don't know if to abandon/Discard it or wait it out as there is no progress indicator

Thanks
 
The times it takes to run restore varies greatly on the size & amount of files, but 56 hours is way to long even if it would be filled only with 1KB files.

Try pressing ^t, this sometimes gives a status indicator. Not sure if this is also true for restore though.

You don't see any DMA_TIMEOUT messages in dmesg output?
It's always worth doing a HDD check anyway, MHDD is an excellent tool for doing so...

There's also a verbose flag for resture. You may want to restart with that turned on.
 
^t =>
load: 0.00 cmd: restore 92 [getblk] 0.51u 1.44s 0% 7116k

but unsure of how to interpret output
and can't expect a man page either

going to try a restore -vrf for now but will run away from the use of restore after this episode.

Thanks

BTW the /tmp directory contains 2 files
/tmp/rstdir...number... 67Mb
/tmp/rstmode...samenumber... 5.5Mb
 
Something very wrong. I dump/restore from motherboard cabled hard drive to USB flash drive stick. Dump total combined file sizes for /, /var, /tmp, /usr is 566MG and the whole thing runs in 23 minuts.
 
You must log in or register to reply here.
Back
Top