Thanks to all who responded:
"Alvarez, Cynthia" <Alvare2C_at_kochind.com>
"John J. Francini" <francini_at_progress.com>
alan_at_nabeth.cxo.dec.com
Ian Mortimer <ian_at_physics.uq.edu.au>
It turns out that cpio, vdump|vrestore, and rsync (which was suggested) all
create new directories on the fly, so they will have "current" date/time
stamps as opposed to the originals. Now, that's what we did the last time we
moved files, and it was decide that it wasn't good enough this time.
I decided to go with a 'tar cf - /dir1 | (cd /dir2tar ; xpf - /dir2)'
pipeline, like in the tar manpage. I did some testing before actually starting
to move data, and it seems to be handling weird characters and named
pipes/links/etc well.
Original question:
On Wed, 07 Jul 1999 15:09:51 CDT dbongert_at_ssc.wisc.edu wrote:
> I realize that something similar has just been asked, but it doesn't fit our
> needs.
>
> Situation: we just got a 400+ Gb RAID system, have partitioned it thusly: 1
> file domain, with many file sets on top of it, replacing our spaghetti mess
> of disks next to our file server. Now we have to move the data to its new
> location, and I am looking for suggestions.
>
> The last time we did something like this, we wrote a script that called cpio
> on each file, and did various tests to make sure the file got copied
> correctly, and that the weird characters in the file names didn't get munged.
> The subsequent testing needed took much longer than the copy, and we're
> hoping to avoid it this time around.
>
> Now, the suggestion that came up recently was to use vdump | vrestore
> (there's even an example of such in the man page for vdump). This would be
> perfect, and we could be reasonably assured that the old and the new would be
> identical, except for one thing: in my test runs, the date on the new files
> is changed to the current time. This isn't acceptable, since our users use
> date stamps for many things. Is there any way to force vrestore to restore
> the original times? I can't seem to find any mention of that in the man
> page. Barring that, are there any other suggestions?
Dan Bongert dbongert_at_ssc.wisc.edu
SSCC Unix System Administrator (608) 262-9857
Received on Fri Jul 16 1999 - 19:56:09 NZST