Problem in backup

[Swain]

I have returned a script (attached)for taking backup of user files on system. I have tried it for 2 users and need to apply for 300 users. Facing following error while running script.
$ INITIALIZE/MEDIA_FORMAT=COMPACT NUS$MKC600: DKD400
$ MOUNT/FOREIGN/CACHE=TAPE/MEDIA_FORMAT=COMPACT NUS$MKC600: DKD400
%MOUNT-I-MOUNTED, DKD400 mounted on _NUS$MKC600:
$ BACKUP/VERIFY NUS$DKD400:[000000...]/BY_OWNER=[130,220] NUS$MKC600:JZIEGLER.SAV
%BACKUP-W-MOUNTERR, volume 1 on _NUS$MKC600 was not mounted because
its label does not match the one requested
%BACKUP-I-OPERASSIST, operator assistance has been requested

I got this help.

User Action: At this point, the Backup utility allows you to either quit
the operation, overwrite the volume label and continue, or put
a new volume in the drive and continue processing. To abort
the operation, enter the QUIT command at the BACKUP> prompt.
To overwrite information in the volume header and continue
processing, enter the OVERWRITE command at the BACKUP> prompt.
To restart the operation with a new volume, enter the NEW
command at the BACKUP> prompt. If the QUIT or NEW command is
chosen, the Backup utility automatically dismounts the volume.

Tried same with changed tapes, but no luck.

Any quick suggestion?

[Volker Halle]

Amaresh,

when writing to tapes, BACKUP compares the tape label with the tape label requested for the backup operation. If not specified via /LABEL=xxx, it defaults to the first 6 characters of the saveset name.

So you can use /IGNORE=LABEL to completely turn off BACKUP label processing. Or you can login as a tape operator ($REPLY/ENABLE=TAPE) and issue a REPLY/TO=n "OVERWRITE" after a REPLY/STATUS, if you backup job is waiting for operator action, to allow BACKUP to accept any tape label.

Volker.

[Andy Bustamante]

You can also add the /LABEL switch to your backup command, or use the /LABEL and /IGNORE=LABEL in combination to have initialize tapes with the label of your choice.

Don't forget to run trial restores whatever option you elect.

Andy

[Art Wiens]

Why do 300 passes on the same disk? Just back it up once and do selective restores when you need to. Depending on the disk hardware, reading through 300 times is probably not the most efficient use of resources. It's all going on the same single tape anyways.

Cheers,
Art

[Shriniketan Bhagwat]

Hi,

If /IGNORE=LABEL is used, it will overwrite the tape label to first six characters of the saveset name. If you need the tape label not to get modified, then use /LABEL= qualifier.

Regards,
Ketan

[Swain]

Hi Art,

Thanks for the suggestion.

I have a full image backup of disk. When I try selective restore, I am getting error (disk is not file structured). How can I get individual files restored?

Thanks,
Amaresh

[Joseph Huber_1]

On a non-image restore, the output disk must be mounted.
If the error is something else, show us the exact command and error message.

[Bob Blunt]

You should also modify your "script" to use the same available switches for the BACKUP command string as you are on the MOUNT command AND you should definitely include the /SAVE switch... For example:

BACKUP/VERIFY NUS$DKD400:[000000...]/BY_OWNER=[130,220] NUS$MKC600:JZIEGLER.SAVE/SAVE/MEDIA_FORMAT=COMPACTION

I also agree that you have more efficient options for your archival. There are many methods and schemes available. /IMAGE and /INCREMENTAL, variations using /RECORD and /SELECT... No matter if you're using DLT, SDLT, DAT, 8mm, all of them already make multiple passes across the tape head and the media wears faster than you might expect. Performing one "big" backup for all the users should, hopefully, mean fewer passes across the mylar.

[Steven Schweda]

> [...] AND you should definitely include the
> /SAVE switch...

Why? When did /SAVE_SET stop being the
default for a tape?

> [...] Performing one "big" backup for all
> the users should, hopefully, mean fewer
> passes across the mylar.

While one job might be more efficient for
several reasons, unless one rewinds the tape
between jobs, it's not obvious to me why this
would be true.


> If the error is something else, show us the
> exact command and error message.

No matter what the problem, show the actual
command with the actual message. Or else
call a psychic hot-line.

[Shriniketan Bhagwat]

Hi,

For selective restore the disk should be mounted and use /SELECT qualifier to restore the selected files. To restore the full image backup from tape to disk, the disk must be mounted foreign.
$ MOUNT/FOR

Thanks and Regards,
Ketan

[Hoff]

>Any quick suggestion?

Yes. Stop using BACKUP. Go try the BACKUP$MANAGER utility. The latter approach is somewhat better suited for more modern preferences toward computing interfaces. The syntax of the former is as close as OpenVMS gets to a Unix bash shell command; it's cryptic and somewhat hazardous.

[Swain]

Hi,

Thanks for all your help!

I used following command.

BACKUP/IGNORE=(INTERLOCK,LABEL)/NOCRC/RECORD/NOASSIST/VERIFY NUS$DKD400:[000000...]/BY_OWNER='UIC' NUS$MKC600:'USER'.SAV/MEDIA_FORMAT=COMPACT

It works fine. But it's very slow. Any suggestion for performance improvement ?

Thanks,
Amaresh

[Steven Schweda]

> [...] But it's very slow. [...]

Define "very slow".

You're asking BACKUP to scan the whole disk,
looking for files owned by UIC. Did you
expect that to be very fast? And then, I
assume, you do it for more than one UIC.

Why are you using /BY_OWNER here? How useful
is it to make a separate save set for each
user?

[Jon Pinkley]

Use the /FAST qualifier (no kidding, see HELP BACKUP/FAST)

In the backup command you gave, you are requesting that backup look at every file on the disk to see if it is owned by the specified UIC. The /FAST qualifier tells VMS BACKUP to scan the indexf.sys file to find all the files to backup, so it does not have to do a complete directory tree traversal. This will be faster than the command without /FAST. For image backups, /FAST is the default.

Unless you restore files much more frequently than you make backups, then if you want to save time, do not use individual backup savesets for each UIC, unless you are only backing up a small subset of all user UICs.

While your example command will backup all the files owned by the user, why are files owned by a specific UIC spread all over? That is not typical, and implies that directory protections may be a bit more lax than normal.

Jon

[Volker Halle]

Amaresh,

unless you describe the purpose and use of this type of 'per-user' backup, you cannot really expect useful suggestions.

BACKUP is normally used to save data, which you hope to never need to restore, so you try to speed up your save operation and use a BACKUP/IMAGE, to make sure you've saved all the data on disk. Then - if the need arises - you can restore individual user's files from that image-backup.

But there may be other uses for BACKUP and your's may be a special case. If so, then please explain...

Volker.

[Swain]

Hi All,

Thanks a lot for your suggestions.

> unless you describe the purpose and use of this type of 'per-user' backup, you cannot really expect useful suggestions.

This is a disk clean activity to avoid space issues. There are 300 disabled users on this system. We are archiving old data of disusers, which may need a user specific restore if we need to make these users return (/flags=nodisuser) in future.

> Define "very slow".

Thanks for describing the reason. Now I got the answer.

I am doing it for first time. Please nvm.

Thanks,
Amaresh

[Steven Schweda]

> [...] may need a user specific restore
> [...]

Does that require separate, user-specific
saves? Does each user have files scattered
all over? What you're doing may make sense,
but it's not obvious that it does.

[Swain]

Hey Steve,

Please let me know how can I restore files owned by a single user/UIC from an image backup of the whole user_disk(DKD400).

Thanks,
Amaresh

[Richard Brodie_1]

Something like:

$ BACKUP/VERIFY NUS$MKC600:JZIEGLER.SAV /BY_OWNER=[130,220] NUS$DKD400:[000000...]

[Steven Schweda]

> Something like:
> [...] /BY_OWNER= [...]

Not really. HELP BACKUP /BY_OWNER explains
the difference between /BY_OWNER as an input
file-selection qualifier and as an output
file (or save set) qualifier.

> [...] Does each user have files scattered
> all over? [...]

If so, then you may need to do what you
propose. In my experience, it generally
makes more sense to divide the data by
function (often by top-level directory) than
by owner, but your situation may be
different.

[Jan van den Ende]

Re Richard

>>>
$ BACKUP/VERIFY NUS$MKC600:JZIEGLER.SAV /BY_OWNER=[130,220] NUS$DKD400:[000000...]
<<<

Better make that
... NUS$DKD400:[*...]

or you might create an extra directory level of
000000.DIR

And IF you do that, it can be pretty convoluted to untie that knot.

As a general rule, always try to prevent using 000000 as directory in ANY command. Either specifying * or leaving it out totally will prevent (sometimes MUCH later) problems.

fwiw

Proost.

Have one on me.

jpe

[Jon Pinkley]

> > Something like:
> > [...] /BY_OWNER= [...]
>
> Not really. HELP BACKUP /BY_OWNER explains
> the difference between /BY_OWNER as an input
> file-selection qualifier and as an output
> file (or save set) qualifier.

Regardless of what the help says, it does work as suggested by Richard. The /BY_OWER is treated as an input qualifier whether it is a disk or a save set, at least in 8.3 (this is the only one I have tested with, but I believe it has been this way for a long time). It still has limited usefulness, because it can only be used to match a single UIC, and using /NOBY_OWNER is the same as leaving the qualifier off. In other words, I don't think there is a way to choose files that don't belong to a UIC (the way that the ACCOUNTING utility can exclude PIDs)

See attachment for a reproducer.

Jon

[Richard Brodie_1]

> Better make that ... NUS$DKD400:[*...]

Oh yes, I just rearranged the original command without looking too hard.

[Steven Schweda]

> Not really. [...]

Oops.

> Regardless of what the help says, it does
> work [...]

Right. My feeble brain was thinking "save"
and "restore", but BACKUP works with "input"
and "output", as the HELP says.

So, we seen to agree that a separate save set
for each user is not a good idea.