OK, back on this subject again... Suppose the drives were from the Lilith/Eve workstations. Would the unix trick of using dd still work? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

In article <45B1224F.8040102 at bluewin.ch>, Jos Dreesen / Marian Capel <jos.mar at bluewin.ch> writes: These are definately Eves and not Liliths; I'll post some info. With my installation of shelving in my basement, I can get to the Eves again. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

Ray Arachelian wrote: Usual warnings about compressing anything that's a 'critical' archive presumably apply (I'm not sure how good gzip is at recovering from errors, but most compression schemes seem pretty bad) Sadly I'm drowning in raw disk backups here because software and/or OS media to allow "proper" backups for various systems has long gone :-( Incidentally, I've had some successes in the past in migrating 'alien' OS installs from failing drives to new ones via raw data copies; often the OS doesn't care if a raw backup is restored onto a larger disk - it'll just see lots of wasted space at the end of the drive. Some OSes will record drive geometry somewhere in their partition data structures though, and may rely on it at some stage, so: a) If the system's in a runnable state, search for any info you can find on the disk layout (gleaned from man pages for the format/partitioning programs, C header files etc.) and keep them in plain text outside of the raw drive backup. b) Make sure you have a note at least of the drive make / model, and preferably any info you can find on geometry, transfer times etc. ... that way if the drive does go bang you aren't left scratching around for an identical replacement. It's also useful knowing the partition format in case you might want to try mounting the filesystem(s) on a more modern system at some point (e.g. dd the raw partition out of the drive image and mount it as a filesystem using a loopback device under linux) Worth having conv=noerror,sync in there too, just in case the disk is getting a little tired. Actually, sometimes subsequent re-reads will be successful for bad blocks - I've hacked together scripts before that auto-retry failed blocks several times just to see if the source drive can eventually be coaxed into supplying data. Oh, some systems store data on disk in byte-swapped order (my NCR tower's one). Not relevant for a raw backup / restore, but it's just a gotcha to look out for if you want to try interpreting data on a modern system (or even just browsing in a hex / text editor) cheers Jules

Yup! Even nicer, if you have ssh setup (or rsh, yuck) you can actually dump it to another machine: dd if=/dev/whatever | bzip -9 | ssh otherhost "dd of=/bigdrive/mydisk.dd.bz2" I'm not sure that slice2 on a sun machine will include the boot sector, but it will include the partition table, so you'll want to get details for whatever system you're running. I'm not sure that you'll want to use the raw device name there however. Another choice would be ufsdump or whatever it's called on your system (possibly fsdump or just dump.) Richard wrote: