Moving large backup file

[odwillia]

I need to access a large backup file created on Server1, from Server2. In a cluster, not a problem...except....Server1 currently "cleans out" the space that holds the file daily. We may need the file for longer than that. Any ideas?
The current disk holding the backups on Server1 has only 9.6M free blocks when a backup file is residing on the disk. So it will only hold one at a time.
Currently, a backup file is approx 61M blocks.

[Volker Halle]

Hi,

maybe you just need some more disk space somewhere ?

Note that you can put the output saveset (or the input saveset) onoto another node in the network, as BACKUP uses RMS to read/write the saveset and this implies transparent access via DECnet.

$ BACKUP local_disk:[*...] node::dev:[dir]saveset.bck/SAVE

OpenVMS V8.3 allows backup saveset compression. Although this function is not yet supported, it may save a lot of space (and time) when creating an on-disk saveset.

Volker.

[Jan van den Ende]

odwillia,

of course some clever schemes can be worked out, but in earnest, you need to ask your management what several days of work (not to mention testing, and potential risk) costs, compared to the hardware cost of a decent disk drive.

Nothing fancy, no ultra-speed, just the storage.

If they do have a rudimental knowledge of arithmetic, by FAR your best option is an extra drive.

(and in the unlikely event that you are really out of connectivity options for another drive, replace the smallest drive with a moderately modern one. The tremendous gain in storage capacity will be counterbalanced by a big SAVING in power consumption!)

hth

Proost.

Have one on me.

jpe

[odwillia]

I agree. Its a big battle just to add a little storage...maybe I can convince them its the best way to go.

[Robert Gezelter]

odwillia,

I would check out the latest versions of ZIP/UNZIP for applicability to this problem.

While there are no guarantees, depending on the data, a large savings can be realized by compressing the save sets. If the file is needed in its uncompressed form, UNZIP is quite efficient.

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

[Jan van den Ende · Accepted solution]

odwillia,

by all means, if you think it can have a positive effect, USE me posting. in any way that suits you!

If it turns the scale, I will have done my good deed for today! :-)

Proost.

Have one on me.

jpe

[Art Wiens]

Is there a tapedrive on either system? They have been known to store files for days. Restores are also usually possible! ;-)

Is there another system on your network somewhere that has a bit more disk space? Perhaps arrange for space there and transfer the file (FTP, SCP etc) as temporary storage.

If the requirement is for ongoing, online access to several copies of this backup file , then mgmt should be made to understand it _is_ a requirement and to spend a few bucks.

Cheers,
Art

[Jon Pinkley]

As others have said, you need more disk space. And just to be clear, you said the file is 61 Million Blocks, or 30.5 GB, correct?

Consider this: If some other process creates a 10 GB file on the disk after the cleanup process runs, but before your file is copied, you won't be able to store your backup file there.

What is the percentage of free space on this Server1 disk?

If the file is 30.5 GB, then zip (currently supported versions) will not help, as I believe each member of a .zip file on VMS must be less than 2^31 bytes (~2GB).

Good luck,

Jon

[Jon Pinkley]

Matt,

My guess is that you are renaming the file. Do you have a command procedure to purge to n versions and reset the version numbers? A rename will change the revision and the modification data.

It appears something other than an editor is opening your login.com file for write. Even if no changes are made, the revision date will be changed when the file is closed. (I wish there was an option so this wouldn't happen unless there was actually a write operation done).

Do you have a "touch" utility on your system? Or perhaps a third party tool that searches files, but doesn't open them for read only access?

Note the date stamp. What runs then? You could use image accounting or put an audit ACE on the file and use auditing to determine what is doing it.

Note the revision count (293). This has been "modified" 293 times since 15-SEP-2005, or something is changing the timestamps and revision count.

Jon

[Jon Pinkley]

Sorry, zero points for previous reply to Matt, which was a reply to a different thread.

Jon