VMS Backup on v7.3-2

[Jorge Cocomess]

Greetings,

My backup log displayed an error for writing toward the end of my backup for one of the disk volumes. Does anyone know what's the cause of this error and should I worry about this error? This is a backup com procedure that backs up 3 disk volumes within a single procedure.

This is a VMS backup procedure.

%BACKUP-I-WRITEBACK, error writing backup date for DISK31: file ID (20449,109,0)
-SYSTEM-W-NOSUCHFILE, no such file


Thank you in advance.

J

[Phillip Thayer · Accepted solution]

J,

This error will happen when you backup a file that then gets deleted off the disk before the backup date is weritten to the file. This is nor a problem to worry about. It is for information only.

Phil

[Jan van den Ende]

Jorge,

specifically, this error can only occur when you have /RECORD in your BACKUP command, and there is activity on the target disk.
If you check your backup report ( if you did /LOG or /LIS ), then you WILL find this file backed up, but a DIR will NOT find the file.
Backup first does a full inventory, then writes it all to tape (or any target saveset), and only then writes the BACKUP DATE. Files might be deleted in between.
(a related error is "Error reading file ...etc, if the file was deleted after inventory, before including in the saveset)

hth

Proost.

Have one on me.

jpe

[Jorge Cocomess]

Gentlemen - Thanks so much for your response. One quick question, what should I do if I'm going to backup the target drive with open files? I have used command such as, "/ignore=(inter, label)" with my image backup.

Yes, I do have 2-3 target drives that possibly have open files. I did a set file mark "nobackup" for the log files that I didn't want to backup during my backup procedure.

I am very gracious for your feedback.

Regards,

J

[Steven Schweda]

As the HELP (V7.3-2) says:

NOTE

File system interlocks are expressly designed to prevent
data corruptions, and to allow applications to detect and
report data access conflicts.

Use of the INTERLOCK keyword overrides these file data
integrity interlocks. The data that BACKUP subsequently
transfers can then contain corrupted data for open files.
Also, all cases in which these data corruptions can occur in
the data that BACKUP transfers are not be reliably reported
to you; in other words, silent data corruptions are possible
within the transferred data.


If the buffers have all been flushed, and if
the files are idle, then the results should
be good. If not, then the data will not be
perfect. How stable, and how important, are
the data in the open files?

[Jorge Cocomess]

Steven,

These files are mostly log files. They are not that important. However, I just hate see these errors that's all.

Thanks,
J

[Steven Schweda]

If you hate them enough, you boot in a more
minimal way, and/or from another device
and/or [SYSn] directory. That is, Standalone
BACKUP (VAX), or a CD-ROM, or something like
that.

If you don't hate them that much, then you
probably have to live with them.

[Jan van den Ende]

Jorge,


However, I just hate see these errors that's all.


Well, they ARE not errors!
Look at that single letter betrween the two "-" : "I" means Informational.
The slightly more serious messages are -W- , for Warning. Next comes -E-, those ARE errors. And finally there is -F-, for Fatal (or Severe) error.
The difference between -E- and -F- is for instance: -E- : a file that BACKUP found in the inventory phase got deleted before it was its turn to be read: -E- FNF, file not found. But the Backup can continue. -F-: the tape has "lost position" and cannot recover. Now the whole Backup has to be stopped.

hth

Proost.

Have one on me.

jpe