migrating data between two disk arrays

[itai weisman]

hello,
on Open VMS 6.2 running on Alpha 4100 (an old legacy server, unable to upgrade anything) - how can I migrate a low usage device (uses about 20% of disk space) to another disk, that has enough capcity to hold all used space, but its total capacity is lower? can I use backup/image? if not, what other host based migration is possible (I have to keep file permissions, acls etc)
Thanks ppl.
Itai.

[Robert Gezelter · Accepted solution]

Itai,

BACKUP/IMAGE is the correct way to do it. So long as all of the data will fit, you should not have a problem (BACKUP/IMAGE does not preserve the physical space allocation, LBN/cyl-track-head), it preserves the logical structure of the disk.

It is too bad that you are not running 7.3-2 or later, then you would be able to accomplish the transition using host-based volume shadowing without even interrupting users (see "Migrating OpenVMS Storage Environments without Interruption/Disruption" from the 2007 HP Technology Sympoium; notes at http://www.rlgsc.com/hptechnologyforum/2007/1512.html )

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

itai,

BACKUP/IMAGE is just the tool to use.

The issues that might arise are in the addressing of the stuff you move to the target drive.
If you are able to give the target the same naming, that would be great.
If all access is "clean", by way of logical names derived from concealed devices, then you just change the concealed device translations, and everything is fine.
If the current device(-name) is leaving to never come back, a quick-and-dirty trick would be to set up the current device name as a logical name that points to the new device. Bear in mind that in that way you TOTALLY BLOCK any access to any future device that receives that name.

Succes!

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Are the file in active use?
Can you shut down the application.
Please do NOT use /BACK/IGNO=INTERLOCK.

Do you need to retain anything on the target disk?
In that case I would suggest to just use backup to copy/merge
BACK old:[*...] new:[*...]

Clean target?

BACK/IMAGE can be used and retains file-id's which is unlikely to be critical, except for a system disk. This is an opportunity to chose nice INIT params.
I'd suggest
$INIT ...
$BACK/IMAGE/NOINIT ....

You indicate there will be enough SPACE, but what about SPEED? Will the target now become overloaded?

Finally, if the source has significant RMS INDEXED FILES, then you may want to use the opportunity to use CONVERT to copy the files and clean up teh internal structure as you go.

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[itai weisman]

thank you all for your quick and helpfull answers.