Remote FS mount?

[John Payne_2]

We are preparing to migrate a LOT of data from an old D class box to another box attached to a SAN. We can not attach the D class to the SAN, so we are looking for a good way to migrate the data. (We are talking about 350+ GB here...)

Running a tape backup and restoring to the new box is a feasible option for us, but that is about 36 hours backup and 36 hours restore time. We want to see if we can greatly reduce that timeframe to reduce downtime.

We could nfs mount the filesystems and move stuff over that way, and we could ftp the stuff over, but this may take longer than a backup and restore.

The other idea that someone had was to do something like a remote mount (different from nfs) of the filesystem and use dd or cpio to do a file by file copy. In theorey, this would take a lot less time to move because we wouldn't have to wait for the silly buffers to fill, it would just move things as it got them.

The question is, does anyone know how we would 'remote mount' the filesystems from the old box to the new box? Also, what is the best way to copy the data once we have the mount in place?

We are coming from and old D270 with HPUX 10.20 and converting to an rp2470 fibre attached to a SAN.

Thanks

John

[Rodney Hills]

For transmitting a lot of data over a private network, I would compress the data on the source side and uncompress on the other. You transmit a lot less data over the network that way. It's trading CPU resources for network bandwith.

Example-

cd sourcedir
tar cf . - | compress -c | remsh newsystem "cd newdir ; zcat - | tar xf . )

(or something similar...)
-- Rod Hills

[Rodney Hills]

Oops, I got my syntax a little off. Should be-

tar cf - . | compress -c | remsh newsystem "cd newdir ; zcat - | tar xf - )

You would then setup remote login into your new system from the old system.

-- Rod Hills

[Jeff Schussele]

Hi John,

I don't know of any other standard way to remote mount in HP-UX other than NFS. There may be 3rd party apps out there but I'm unaware of them.
If you have reasonable network bandwith, you should be able to NFS mount the D data to the RP & copy it over - at least at night. Or whenever traffic is lowest. I wouldn't make it any more complicated than it has to be.

Rgds,
Jeff

[John Payne_2]

These are images. We will not get anything out of trying to compress them. Also, this is a major migration. (It accomanies a data center move) The application would have to be taken down and the data moved all at once.

Thanks

John

(Points are coming, but I want to leave the thread open...)

[S.K. Chan]

I do not know the nature of you data but I can share with you what I've done before when dealing with large data migration (in my case about 60GB).
2 servers (A - old ; B - server that has access to a NAS device ; remsh has to work between both servers).
On B ..
# cd /data/new-location
# remsh A "cd /data/old-location;find . -xdev|cpio -coax"|cpio -icvdmuxla
Data from /data/old-location in server A cpio'ed across to B in /data/new-location. It was reliable and reasonably simple enough. I do not know though if this is the fastest way.

[Rodney Hills]

If you have any free scsi controller connections on the new system, maybe you could yank the disks out of the old system and hook it up to the new. Then you could do local copies which would be the fastest.

(You're probabily right about not getting to much savings by compressing if these are images.)

-- Rod Hills

[A. Clay Stephenson · Accepted solution]

If it were me, I would buy some HVD SCSI controllers for your new box and do a vgimport. That is hands down going to beat any other transfer.

The other thing to keep in mind is that you could do a combination of network and tape transfers. Also, while the entire backup and the entire restore might take 36 hours each, it does not follow that the total time must be 72 hours. You can backup and restore in say 1 hour chunks and keep both tape drives active most of the time.