Has backup/image/ignore=interlock become useless?

[Wim Van den Wyngaert]

I did a test with a disk under usage. Files wre being created in reverse (1000, 999, ....).

The directory was backuped with more entries than when the backup started. The entries themselves were not backuped. Thus anal/dis says "invalid file identification in directory".

Anal/dis also found that some file that are/were present were not in the directory ("not found in dir"). This because they moved to another (new) block).

So, make sure to do anal/dis after the restore.

fwiw

Wim

[AEFAEF]

Wim,

Somewhere in the docs or perhaps ECO release notes there is exactly that advice: Run ANAL/DISK after a BACKUP restore operation.

AEF

[Richard W Hunt]

Too many years ago I worked on some utilities since obsolete because DEC (yes, that long ago) and some 3rd-party vendors eventually provided what I needed.

I learned that when you bypass the file system and "roll your own" QIO ops, you also don't track the contents of the DIRID cache or HDRCACHE. ANAL/DISK is capable of doing this, and the file system knows what is in the cache, too. However, if something changes in a directory, it changes in the cache first. THEN it gets written back to the disk based on write-behind settings. But with an unpredictable and untrackable delay.

As to a comment I read in passing, EMC always tells you to quiesce anything you are trying to replicate. They even have white papers on the subject. (Don't have the URL for you, haven't used my PowerLink account in ages.) But the comments about using your apps to perform backup is spot-on. We had a devil of a time getting ORACLE backups that meant anything at all until we started used RMAN and forced log-file switches afterwards. Then we could use the RMAN file and the stored log files to recover our files elsewhere.

The idea of doing a shadow-split also doesn't work if you have controller-based shadowing, which is often what you have for HSG or EMC fiber-attached storage. Bottom line, it is nearly impossible to quiesce a disk enough to make a really good backup.

I believe this can be traced back to the lack of a file-system primitive that could be issued against a device, perhaps even as a diagnostic-class command requiring beaucoup privilege, to flush all pending QIO write-behind buffers for a given disk. Granted, probably almost impossible to do, and in a clustered environment, even closer to impossible than in a stand-alone case.

My approach, which clearly would not work for the system disk, was to dismount and remount the volume I was about to replicate, and then live with the fact that I was taking a point-in-time snapshot. But at least I knew WHEN the point in time had occurred.

[Ian Miller.]

According to Kirby then the caches can be flushed by taking out a write lock on the appropriate F11B$c lock. This could be done by opening BITMAP.SYS and INDEXF.SYS for write.

Perhaps pausing the writes then SET VOLUME/REBUILD/FORCE might do it.

[comarow]

I went back and reviewed this. It seems you
have a shadow set for your system.
Backing up any in use drive can lead to problems. If a directory is altered, you can lose files in the directory.

But you have the PERFECT Solution.

Dismount one of the shadow disks. Mount it privately and create the backup save set.
It will be supported, works great, and will
give you great peace of mind.

If you are afraid of losing your one and only disk, you can shadow up an extra disk and use that. In any case, you still have the dismounted copy of your system disk.

What is the problem with a supported, simple
solution?

Bob Comarow

[Ian Miller.]

The supported process for backups using shadowed disks is described in the fine documentation

http://h71000.www7.hp.com/doc/732final/aa-pvxmj-te/00/00/70-con.html