Operating System - OpenVMS
1748038 Members
4923 Online
108757 Solutions
New Discussion юеВ

Re: Backup taking locks ?

 
Wim Van den Wyngaert
Honored Contributor

Backup taking locks ?

I was experimenting with backup/image of a disk with a lot of activity.

While the backup was running, I created lots of files with names in decending order.

The file creation aborted with "file currently locked by another user". Tried it with ascending names. Idem. Without /image. Idem.

So, any backup can cause file creation failures ?

Wim (hoping I miss something)

Wim
Wim
12 REPLIES 12
Wim Van den Wyngaert
Honored Contributor

Re: Backup taking locks ?

VMS 7.3 in a cluster and file creation done with
$ create xxx
a
$

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

Re: Backup taking locks ?

All tests redone with ignore=interlock. Then the file creation never fails.

So, interlock not only means "able to read all files" but also "don't lock" ?

Wim
Wim
Ian Miller.
Honored Contributor

Re: Backup taking locks ?

/ignore=interlock means don't lock and hope
____________________
Purely Personal Opinion
Wim Van den Wyngaert
Honored Contributor

Re: Backup taking locks ?

What is not what I read in the help text.

Wim
Wim
Jon Pinkley
Honored Contributor

Re: Backup taking locks ?

Just curious, did it report which file was locked?

It seems the only one that could cause problems for creating files would be the .DIR file.

And yes, backup without /ignore=interlock can lock files and cause other processes to get file locked by another user errors when they attempt to open the files for write access.

There have even been reports of login failures due to SYSUAF.DAT being locked.

it depends
Wim Van den Wyngaert
Honored Contributor

Re: Backup taking locks ?

It didn't say that it was the directory file.

Can it also happen that something gets locked when using /ign=int ?

Wim
Wim
Jon Pinkley
Honored Contributor

Re: Backup taking locks ?

I am reasonably sure that if /ignore=interlock is used, only files that backup is creating, for example your journal file, log file, listing file, or output saveset will get locked. If they are on a different disk than you are backing up, and you use /ignore=interlock, backup should not interfere (locking wise) with other users of the source files being read by backup.

In other words, I am not aware of any locking that the BACKUP image would do to cause file locked errors for other processes.

But how useful the resulting backup would be is the question you have to ask, if there is a lot of activity on the disk. I assume you have been following the other backup thread:

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1338782

If you have a test system, try the SDA LCK extension and collect a trace of locks while you are doing your test.

I am not sure how a movefile operation (defragmentation assist) is synchronized with files that are opened with "explicit interlock ignore". I remember reading somewhere that you should avoid backups while defragmenting disks, but I don't remember where I read it, and whether it was due to performance effects, or consistency effects.

Jon
it depends
Hoff
Honored Contributor

Re: Backup taking locks ?

AFAIK, online application backup is not available on OpenVMS with the integrated tools.

High- or continuous-uptime application data archiving is not an easy problem, and it usually involves the assistance of the application(s) and (usually) replication, and (increasingly) the direct assistance of the database and the file system.

You can (and usually should) (also) use database-integrated tools, such as mysqldump or RMU/BACKUP or such; these are synchronized with the data source, and can provide (more) consistent results.

It is possible to get rather close to this goal with OpenVMS with the use of the (optional) RMS Journaling pieces.

There are other issues with the current implementation of BACKUP (beyond the locking-related matters), not the least of which are the bandwidth limits inherent in the current design; the current tool is within a close percentage of the theoretical limit of the bandwidth of the underlying devices and I/O buses. Avoiding the increase in archival time then tends to point to data compression (which is latent but as yet unsupported) or reducing the quantity of data involved in getting the archival copy, or toward parallel archiving or faster hardware. Or a combination.

There's certainly fodder here for a Best Practices article or two, as the features and limitations of the OpenVMS tools are (clearly) not (widely) understood.
AEFAEF
Advisor

Re: Backup taking locks ?

Wim,

I had exactly this problem once. I was backing up our archive disk, and the backup ran long. The EOD job was running on another server. At the end of this job it copies trading-data files to the archive disk. Several files couldn't be created. I suspect that BACKUP had the directory locked (or one of its blocks?) at that time.

As recently mentioned here in the /ignore=interlock post, it is best to run BACKUP when things are quiet.

AEF