topic Re: Backup in Operating System - OpenVMS

Backup

geir_2 — Wed, 11 Jan 2006 08:21:27 GMT

I made a DCL script for incremental backup, but I have some trouble with some files.

I use following qualifiers: /since=backup/record/modified/ignore=interlock

But create time & modified time doesn't change on the actual file, even though the file is bigger/changed. Is possible to do something?? I guess the problem is the contents of the fileheader?? Is it possible to modify the fileheader in some way??

Re: Backup

Hein van den Heuvel — Wed, 11 Jan 2006 08:40:07 GMT

Apparently those files are open 'all the time', and a backup is probably useless anyway as you have no control over what data might have made it to the disk, and what is still in the process buffers.

You should teach the application to use SYS$FLUSH every now and then, or re-open a fresh file on command (blocking ast, command mailbox with write-attenion-ast)

You may have to re-think the backup strategy for those files/that application.

If the application allow shared file access (probably not) then you could open it wil write intend, allowing write and just close right away. The intend to modify is enough to change the modification time on close, even if no actual data was changed:

$ open/read/write/share=write tmp some-file
$ close tmp

hth,
Hein.

Re: Backup

Allan Bowman — Wed, 11 Jan 2006 10:54:48 GMT

Geir,

If there are only a few files that are always open (as described by Hein), you can do a separate backup of those files (not incremental). I came from a similar environment where a large number of files were always open, so we always did a full backup. The files may end up out of synch or missing data, but in the event of a major disaster, at least the file structures and some data can be restored.

Allan in Atlanta

Re: Backup

geir_2 — Mon, 16 Jan 2006 09:47:37 GMT

Hi,
Thanks for the answer.

My problem is: I also want to backup the open file, each time I take backup.

I assume it must be possible to include the backup of this file eeach time I take incremental backup. Maybe with help from some qualifiers. (replace, overlay, new_version)

Thanks again
Geir

PS:
Maybe the qualifier is used when the user want to restore the backup from tape to disk.

Re: Backup

Bob Blunt — Wed, 18 Jan 2006 10:52:53 GMT

Geir, /REPLACE, /OVERLAY and /NEW_VERSION are output qualifiers when writing back to disk. Their use should be negligible when creating a saveset (on disk or tape).

Re: Backup

Joseph Huber_1 — Wed, 18 Jan 2006 11:12:04 GMT

If You can't change the applications behaviour to better cooperate (as others suggested), You could make a copy of the files using CONVERT before the incremental backup. Those copies are then included in the incremental backup.

Another way would be to change the revision date for example with a SET FILE/PROTECTION command before the backup.

Re: Backup

Wim Van den Wyngaert — Wed, 18 Jan 2006 11:47:03 GMT

Geir,

If you backup an open file the result is unknown.

E.g. a file allocated 10 blocks that are filled with garbage. The application used 5 of them and wrote clean data to them. But it didn't post the eof. You take a backup. What do you have : file data is fine but eof isn't. Now you could do set file/end but that would allocate the 5 dirty blocks to the file too.

This to say that files must be closed, eof must be posted or you must damn well know what you are doing.

Wim

Re: Backup

Wim Van den Wyngaert — Wed, 18 Jan 2006 11:51:14 GMT

To modify the file I would propose to use freeware touch but I tested it on an file that's open exclusively for write and touch didn't work. Set file/prot did. So that is better.

Wim

Re: Backup

Jan van den Ende — Wed, 18 Jan 2006 12:30:13 GMT

Geir,

to repeat the advice by "Mr RMS" (Hein): the only safe thing is CONVERT/SHARE to get a CONSISTENT file.
This does not work for database systems with their own file structure, but all good once of that have some sort of on-line-backup.
Penalty: performance during the on-line-backup, and an extra action should restore be needed.

Proost.

Have one on me.

jpe