Image backup of disk to a remote node?

[roose]

Hi,

We have setup a test server, Alpha ES40 on OVMS 7.3-2 and plans to copy disks from our production servers. Unfortunately, our tape drive on the test server is already broken, and we are having difficulty in making it as a restore destination when using Networker.

As a workaround, I am currently backing up our production disks to a disk on the production server, then copy the saveset to our test server and do the image restore from there.

I tried to execute the following commands from the test and production server:
On test server:
TEST$ mount/foreign DKB100:

On production server:
PROD$ backup/image $1$DKB100: -
TEST"user password"::$1$DKB100:

but I am getting the error:
%BACKUP-F-INVDEVTYP, invalid backup device type TEST"user password"::$1$DKB100:.;

Is what I am trying to do valid at all? If so, what should be the proper command here?

thanks.

[Steven Schweda]

I don't believe that you can do a disk-disk
image backup with DECnet that way. You may
be able to do it to a DEVnet-remote save set:

PROD$ backup/image $1$DKB100: -
TEST"user password"::$1$DKB300:DKB100.BCK /SAVE

and then do an image restore on TEST from the
(now local) save set (something like):

backup/image $1$DKB300:DKB100.BCK /SAVE -
$1$DKB100:

If the systems are in a cluster, sharing
disks, _then_ you can do a direct disk-disk
image backup (_without_ DECnet).

[Heinz W Genhart]

Hi Rose

I agree a little bit with steven, but you have to change the specification of the destination:

PROD $ MOUNT/OVER=IDE $1$DKB100: ! or mount/SYSTEM
PROD_$ backup/image $1$DKB100: -
TEST"username password"::$1$DKB100:[000000]DKB100.bck/sav

Then to restore on test:

TEST $ MOUNT/FOREIGN destinationdisk:
TEST $ BACKUP/IMAGE $1$DKB100:[000000]DKB100.bck/sav -
destinationdisk:

You have to specifiy a valid destination for the first backup, e.g. node"user passw"::disk:[directory]filename/sav

You could also create a proxy account on test and then do the backup without specifiing a username and password:

TEST $ MC AUTHORIZE add /PROX prod::user_on_prod user_on_test/DEFAULT

PROD $ BACKUP/IMAGE $1$DKB100: TEST::disk:[directory]filename.bck/sav

This should work

Regards

Geni

[Hoff · Accepted solution]

Rule of thumb: The remote portion of BACKUP via DECnet only works with and only allows operations with a single file on the remote host; with the BACKUP saveset file. BACKUP won't do disk-to-disk over the network, and it won't do a local saveset to a remote disk.

If your BACKUP command accesses multiple files as its source or its target, these files MUST be on the local host.

If you're stymied by BACKUP (which is quite common; it's incredibly arcane), I'd strongly recommend reviewing the command examples at the back of the BACKUP chapter. There was an effort to provide at least one example of most any conceivable BACKUP operation in the documentation there. (Most or all of these same examples are also available in the on-line help for BACKUP, too. HELP BACKUP EXAMPLES will get you a list.) Transcribing and editing and using these example commands will usually get you the best results.

And there's also the BACKUP$MANAGER user interface that's available in most any V7 release; a UI which can be a somewhat more gentle introduction to the entirely gonzo BACKUP command syntax.

Another common option for transferring data around is to swap a disk brick around.

Stephen Hoffman
HoffmanLabs LLC

[Robert Gezelter]

Roose,

As Steve, Heinz, and Hoff have already mentioned, BACKUP over DECnet must be to/from a Save Set.

That said, I have found that performance substantially improves if the destination account on the remote node has a default file extension size (SET RMS/EXTEND=x) that reflects a reasonable increment. For large disks, this is one of the larger values. Otherwise, the file will be extended on an ongoing basis, which impacts elapsed time rather significantly.

Personally, I also increase the RMS settings for network access. The extent necessary depends on the actual environment. Accurate benchmarking can save much trouble at a later date.

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

[Jon Pinkley]

I realize this isn't answering the specific question you asked, but have you considered physically removing a drive from the production system and moving it to the ES40?

This won't work if you don't have the same time of drives in both systems, but if you are using the universal SCSI drives on both systems, you should be able to make a copy on the production system (you could even use disk shadowing if you have that licensed on the production system), dismount the copy, physically remove the drive, and put it in the test server.

It's almost a guarantee this would be faster than any network copy.

It is at least something to consider.

Jon

[roose]

Folks, as always, thanks for your time in replying to my query!

John: unfortunately, we are using EMC SAN disks on our production servers. Yes, it would have been easier if we are using local disks and just do a mirror and move the disks to our test server.

Thanks again.