>Can I transfer the whole Image Backup to some External Hard drive from the Disk where Backup is taken through FTP?
Yes, and (with VMS) those external drives are typically connected with SCSI. Not USB. Check your hardware configurations to see if you have an external SCSI connector.
As for the network file transfer of the data, you'll either want to preemptively zip the BACKUP (which also reduces the transfer size) or you'll need to reset file attributes when the file arrives back on VMS.
With zip, use the "-V" option to protect the BACKUP metadata. You'll usually need to quote that -V, too.
If you don't take steps to protect the metadata, the usual metadata corruptions that arise when a binary-mode ftp meets a BACKUP can be resolved with the reset tool in the 000TOOLS area of the Freeware, or with a direct SET FILE /ATTR command if your OpenVMS version allows that.
I'd recommend using zip "-V", regardless. Smaller transfers. And the savesets within the zip archives are protected against the metadata corruptions.
When using zip, you can and should use zip 3 and unzip 6; the current stuff. These fix various problems from the older versions.
The available pre-built versions of zip and unzip are intentionally built on a VMS version older than your version of VMS, so you can use them with your V7.2-1 systems.
http://labs.hoffmanlabs.com/node/575http://labs.hoffmanlabs.com/node/473>Actually I need to take backup of my system (Almost 20 Alpha Open VMS machine(as said earlier) on every 3 months and I need to keep the older backup also.That is why I want to transfer the backup to some higher capacity USB hard drive where I can have all the Backup Images for future restoration.
USB disks are glacially slow on VMS, and your systems (hardware and software) pre-dates all of that regardless. IDE media operations are also comparatively slow.
If you've got the usual backup window to do this, then get yourself a shelf of (used) SCSI disks, and haul those around, as I'm guessing you don't have extra disks on your boxes. Shelves of seven or fifteen 18 GB or 36 GB drives are cheap, and (how these purchases usually get justified) cheaper than loss of your data. That added storage keep your windows smaller, as it's likely you're not working with gigabit Ethernet (which would be a reasonable upgrade), so those added disks will allow you to cache your backup data (and zipped archives) and then transfer your bootable backups later, and you'll also want a disk for booting OpenVMS to get a copy of your current system disk.
>It was not clear to me from the initial query about what does â  corrupted and is highly unreliableâ  mean by the author. Since itâ  s the image backup of either system disk or of the disk where their customized application is running, I guessed it could be the difference in the copy of the files in the save and the disk. Hence I asked him to use the /IGNORE=INTERLOCK qualifier.
/IGNORE=INTERLOCK removes the anti-data corruption "blade guards". It's the anything-goes switch. It's the switch best used whenever you're creating fake backups. When you're not serious about your data. When you want to have a sort-of BACKUP, and with the potential for subtle corruptions.
For more experienced OpenVMS folks, that switch is what you look for to determine if you're likely to have massive (weird) problems with the recovery.
And I've yet to encounter an /IGNORE=INTERLOCK that worked with a system disk without the requirement to manually rebuild the system disk, and (for various system and application files) blowing those away and rebuilding them.
>I asked to use the /CRC qualifier since the tape used here is DAT. Sorry for not being so clear in my previous reply and thanks for correcting me.
DAT uses its own unique variation of the "WORM" acronym. WORM: Write Once, Read Maybe. Those drives and that media were cheaper than other options for a reason; that stuff is just not particularly reliable.
I've managed to get USB to work on a few Alpha system configurations where it's not officially supported - including on an AlphaStation XP1000 box - but - bluntly - it's glacially slow where it does work:
http://labs.hoffmanlabs.com/node/1410Haven't tried USB with Alpha with V8.4 yet. And I haven't tried enabling USB with an AlphaServer DS10-class box; it might not even enable.
My recommendation: get some (used) gear including an old SDLT or two and some old disks or an old disk shelf that you can carry around, as that'll likely be a substantial upgrade.
