Backup

[geir_2]

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??

[Hein van den Heuvel]

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.

[Allan Bowman]

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

[geir_2]

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.

[Bob Blunt]

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).

[Joseph Huber_1]

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.

[Wim Van den Wyngaert]

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

[Wim Van den Wyngaert]

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

[Jan van den Ende]

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