Mark a DIRECTORY as NOBACKUP?

[Jan van den Ende]

Situation:

VMS 7.3-1
Occasionally BACKUP does not fit in one tape, and next morning an operator has to supply a continuation tape and resume BACKUP.
This is a 24 hour shop, most of activity during office hours, but non-negligeable activity at night also.

The consequences: Far less consistent backups as would have otherwise been possible, and severe performance degradation in the early office hours.

Investigation showed the following:
Also during the night a batch job collects all kind of mutations and formats them in "reports" in a format acceptable to another (non-VMS) system.
Those reports are collected into one dedicated directory, and when reporting is done, they get tranferred to the other system. If that is successfull, they are deleted.
Unvariably the tape-full situation happened when this temporary directory had much data in the backup.
And the value of having it in the backup is nill....

BACKUP without /IMAGE but with /EXCLUDE would:
- make the backup procedure much more complicated (now it just processes all whole disks one at a time)
- take much more time

The simple solution looks to be set the files /NOBACKUP.

I do not know the exact programs that make the extractions, they are from a 3rd party.

We tried setting the .DIR file to /NOBACKUP, which is happily accepted, but BACKUP still backups the files (which would be a minor nuisance) AND the data, which is what we try to avoid.



Any ideas anyone?


Proost.

Have one on me.

jpe

[Uwe Zessin]

Can you do a dumb:
$ set file/nobackup ...

just before the BACKUP starts? It won't hit open files I guess, but should turn down the amount at least a little bit.

[Jim_McKinney]

> setting the .DIR file to /NOBACKUP

If the goal is to exclude the data in the files that are "pointed to" by the directory then you'd need to set the NOBACKUP attribute on each of those file individually.

[Jan van den Ende]

Uwe,
Trouble is, there ARE no files yet when BACKUP starts.
And they may already be gone when the BACKUP of THAT drive starts (which is the situation when things go well).

We HAVE already questioned the correctness of the whole setup, since the "moment" of backup of related files is streched for hours, so integrety of a restored system is questionable anyhow.
But the applications are being transfered "ASAP", so any investment in the system will be overruled.
I am rather pessimistic about the duration of ASAP, but it is "politically incorrect" to say so. :-(

Thanks anyway Uwe, but no solution.

Proost.

Have one on me.

jpe

[Walter Miller_1]

I thought the first thing backup did was read indexf.sys and any files created after that scan would not be saved during an image backup. This would make Uwe's suggestion seem appropriate.

[Jim_McKinney]

> during the night a batch job collects all kind of mutations and formats them in "reports"

Perhaps you could modify the batch job code to set the nobackup attribute on each file as it moves them into your target directory?

[Jan van den Ende]

Jim,


If the goal is to exclude the data in the files that are "pointed to" by the directory then you'd need to set the NOBACKUP attribute on each of those file individually.

Exactly that was the intention: hoping it would be ingeretid. Not so. :-(
Ane ACE to trigger that would also be welcome, but I know not of it.

Second idea:
something along those lines is the ugly, hard way to get (near) there. It might well be where this will lead to, if this collective has no more elegant solution.

Walter:
but those scans are performed per disk, therefor, rather spaced in time.


Proost.

Have one on me.

jpe

[David B Sneddon]

Jan,

Is it possible to set up a "scratch" disk for
these files and not backup that disk? You could
also use it for other junk.
Just a thought...

Dave

[John Gillings]

Jan,

Directory files are ALWAYS backed up, regardless of backup attributes. This is required to ensure incremental restores are done correctly.

At the moment there is no way to specify that files created in a particular directory should have the NOBACKUP attribute by default. It has been requested in the past. If you log a case and lodge a formal request for an enhancement, you will increase the weight of the request. Since NOBACKUP is ignored on directory files, the attribute could be used to specify a default for files within the directory.

In the mean time, you could place an ACE on the directory like:

(IDENTIFIER=BACKUP_PROCESS,OPTIONS=DEFAULT,ACCESS=NONE)

and grant the identifier BACKUP_PROCESS to the process that does your backup. Make sure you remove BYPASS privilege. This should prevent the backup process from reading the files. You'll get error messages which will look ugly, but it should achieve what you want. To reduce the number of errors you could block access to the directory from the backup process itself perhaps?

Other than that, you'll need a /EXCLUDE list.

[Steven Schweda]

> Since NOBACKUP is ignored on directory
> files, the attribute could be used to
> specify a default for files within the
> directory.

I've wished for this many times, but I'm not
a profit center.