Stop BACKUP after file is created ....

[ChaimBu]

OpenVMS V6.2-1H3

Is there any qualifier that will cause a BACKUP procedure to stop as soon as the file(s) in the select cause have been successfully created?

I am afraid to issue a STOP/ID on the process fearing that the tape drive will NOT be deallocated and with the process being nonexistant, the ONLY way to retrieve the tape drive will be to reboot.

Thanks,

Chaim

[Karl Rohwedder · Accepted solution]

I fear there is no such qualifier. I normally issue a Control/y and define a ON CONTROL_Y THEN statement in procedures to continue.
If the process runs in batch, you may issue a STOP/ID=/IMAGE (if your VMS version is quite new) or use one of the freeware tools to just exit the image of the process.

regards Kalle

[Volker Halle]

Chaim,

unfortunately, there is no such qualifier or functionality within BACKUP, although this would seem to be a very useful feature.

But depending on the way you've specified the /SELECT qualifier, there may be no way for BACKUP to automatically determine, if there could be any more files satisfying the select criteria.

It would be easy to stop for /SELECT=([dir...]*.*;*), but not for /SELECT=([*.dir...]*.*;*)

Volker.

[Jan van den Ende]

Chaim,

in my experience, BACKUPs with /SELECT clauses are usually one-off. interactive operations.
So, adding the /LOG, you HAVE the info about what has been restored (the log message is only displayed AFTER the restore of that particular file has completed.
So, if the desired files have been processed, issue CTRL_Y, and to the DISMOUNT (or SET MAG/REWIND, as desired).

But yeah, I do agree, a qualifier would be nice. But as Volker wrote, how to construct an algoritm that handles all cases IS a challange...

Just my EUR 0.02

Proost.

Have one on me.

jpe

[Volker Halle]

Chaim,

you may be able to reduce the risk of a stuck IO while stopping backup by:

$ SET PROC/PRIO=0/ID=
$ SET PROC/SUSP/ID=
$ ANAL/SYS
SDA> SHO PROC/CHAN/ID=
SDA> EXIT

If there are no busy IOs to the tape, then do a CTRL-Y and $ EXIT or use a program, that would issue a $FORCEX against the backup process (AMDS can do that as well).

Volker.

[Guy Peleg]

Hi Chaim,

As Volker said, there is no way to
stop the BACKUP operation...can you provide
more details why do you need to stop BACKUP?

Is it becasue you are afraid that several
fils will meet the selection criteria? In
this case you may specify /CONFIRM and reply
with "NO" after the files you wanted
were selected. Another option is to restore
the files to a temporary directory and move
the ones you need. Again, more details
would help here.

Guy

[Volker Halle]

Guy,

I'm seeing this as a classic problem with BACKUP when restoring a top-level directory:

$ BACKUP tape:saveset/sel=([AAA...]*.*;*) disk:[*...]

Once BACKUP has processed, i.e. restored, all files in the [AAA...] directory tree, it does not make too much sense to process the rest of the multi-gigabyte backup saveset waiting for another set of files matching this selection criteria - this will never happen, as the directory files are stored alphabetically within the MFD.

Volker.

[Hein van den Heuvel]

Ouch Guy... you are loosing your touch already ?!

The INTEND of question seemed clear enough to me, allthough the words may have been sloppy.

When you BACK/LOG tape:/SEL=(A,B) and you see both files having been recovered, then you want backup to stop spinning the tape, and do so gracefully.

Now you and I know that backup figured there may be other a and b files which match, so it shoudl continue upon match. But the customer likes to express to backup that a first match on any A and any B will do just fine. That gets tricky when asking for A.*, but it still can be meaningful.

The /CONFIRM suggestion is close... but it is a PRE restore question. If the customer knows of a file which exists on the tape AFTER the target file it would be a nice solution: /SEL=(a,b,x)/CONF
When a and B are seen, and X is prompted for just stop there.

What the customer would really like, an not unreasonably so, is a /CONF=CONTINUE or /MORE or /CONF=POST_RESTORE where the answer can be YES/NO/ONE/ALL/QUIT/EXIT/STOP

And yes I would _LOVE_ to see NO and QUIT and EXIT and BYE and ^Z all be the same because I for one am sick and tired of remembering which tool needs what (FTP: BYE... yuck!)

grins,
Hein.

[Guy Peleg]

>Ouch Guy... you are loosing your touch already ?!

Watch out Hein, I still have the privileges
to delete your entries ;-)

I still stand behind my question to
understand the exact reason for Chaim's
question, In my mind, selective restore
from tape is not a frequent operation.

BACKUP should be able to handle unexpected
errors and exit garcefully. I'll take a look
at the code later but I believe it uses
exception handlers for this. If that's the
case, $STOP/IMAGE/EXIT=USER might help,
but I would not trust it with my life
(plus Chaim is running V6.2-1H3)

Guy

[ChaimBu]

Guy,

HI and much good luck in your new position !!!

The reason is that we have multiple savesets on these tapes. I can almost never know in which saveset the file I selected is to be found. The savsets also transverse more than one physical tape. A normal backup/restore operation can take as long as 5-6 hours (!) when actually the file may have been restored from the first saveset within less than an hours time.

Thanks,

Chaim

[Ian Miller.]

The ability to get BACKUP to ask (after restoring one file) "do you want to keep looking for more matching files" would be a useful option especially on older slower kit.

For me, this would be useful when restoring one file (deleted by a lUser who then asks for it to be restored) from a tapeset containing a backup of all the disks on the system. I usually know the name of the saveset and its usually not on the first tape in the set :-(

Parhaps the lucky (?) person designated to be Guy's successor on the BACKUP utility can add this suggestion to the list.

[Guy Peleg]

I agree this is a good suggestion. I will
forward the suggestion to the current owner
of BACKUP hopefully it will show up in
a future release.

As for the question raised by Chaim - I
think, there is no easy and safe way to do
what Chaim wants....maybe STOP/IMAGE can
help but it requires newer version of the
O/S. If you feel brave enough, you may
attempt to write some code to free up the
device in case it get stuck after issuing
a STOP/ID command.

Guy

[Gregg Parmentier]

If you do a /list during the backup operation, you can search the *.lis files for the specific files you want to restore and only restore from one saveset. Backup will stop at the end of the saveset. It may not stop all the tape spinning, but it will cut down on a lot of it, and it will search through the earlier parts of the tape much faster because it will skip the other savesets rather than reading through them.

[ChaimBu]

Yeah, BUT I believe that the /list operation itself will take a VERY long time - not much, if any shorter than the actual restore operation!

Correct me if I am incorrect.

Chaim

[Karl Rohwedder]

The /LIST is created during the creation of the backups, so it doesn't take extra time.
If you create it afterwards, you're right.

regards Kalle

[Volker Halle]

Chaim,

on the question how to find out, which backup saveset the files are in, this is what BACKUP JOURNAL files are good for. See $ HELP BACKUP/JOURNAL

When using /JOURNAL during the backup save operation, file name entries (together with the saveset names) are stored in the backup journal file on some disk.

When trying to restore certain files, you can first use BACKUP/JOURNAL/LIST/SELECT=filename to find out, which savesets these files are in.

This would at least allow a straight restore from the correct saveset. If the saveset is large, you still would like the additional functionailty of backup stopping after the desired files have been processed.

Volker.

[Cass Witkowski]

If what I recall the backup command only processes one save set. I.e. if you have multiple save sets on a tape, the backup restore command will only work on one save set either the next save set on the tape or one you have specifically named.

I think the request is since backups writes files in order then backup should be able to tell when it has finished recovering all the files specified in the select qualifier once it gets pasts that directory. In this case backup should exit rather than continuing on to the end of the save set.

[Jan van den Ende]

Cass,

What would the algorithm look like with wildcard savesetnames, or wildcard topdirectory specs?
It would be worth considering though if it would disallow saveset wildcards & and topdir specs beginning with a wildcard.
At the very least: SOME challange!

Proost.

Have one on me.

jpe

[Doug Phillips]

BACKUP is first and foremost a utility to preserve data so that it can be recovered if the primary data is lost in some way. That it can do so many other nice things is just a bonus. There. Now that I've stated the obvious:

I've contended for years that BACKUP restore from saveset should stop searching when all files have been processed that can be expected to meet the file selection specs.

The completeness of the file spec (presence or absence of explicit and implicit wildcards) must be considered. If the spec indicates that there could be other files then the search should continue (i.e. no directory specified, wildcard in name). But, once the request is fulfilled, meaning no other file should be expected to match the provided spec, the job is finished.

Such an algorithm is not that complicated and I can't think how such a change would "break" backup.

The current assumption that one saveset can include multiple devices, each having an identically named directory with possible identically named files is completely flawed since save sets do not carry device specs and such a saveset is not restorable. Should someone make such a saveset, then let them figure out how to restore it.

Chaim, since you don't know the complete file spec, you can't provide it to backup so a complete search of the saveset is reasonable.

I wonder, though, how you know where to restore the file if you don't know its "home" directory or how it even got backed up?

Do these files "float" around on your system? Why are you needing to restore files? Are you using backup for achives that must occasionally be retrieved or do users keep "losing" files that they need?

If this need comes up often, maybe some further review would be worth your while.

[Cass Witkowski]

Jan,

If my select qualifier was
/SELECT=([AAA...]*.*;*)

and since Backup writes things in alphabetical order I could assume that once I got the the [BBB] directory (really [AAAA] but you get the point) then I could stop looking for more files since I will not find any more for the [AAA...] directory tree.

[ChaimBu]

Doug,

Thanks for your reply!

I did NOT say that I do not know the full path and filename of the file to be restored. I did say that I dio NOT know in which saveset it resides.

Thanks,

Chaim