leichter@VENUS.YCC.YALE.EDU.UUCP (09/12/87)
After a correct description of standalone BACKUP, the author continues: On the other hand, you don't necessarily need a standalone backup. Except in the case that a file is open for update in such a way that it may be rendered inconsistent (software that takes full advantage of RMS capabilities usually doesn't have this problem; software ported from other operating systems may), you can simply do a "BACKUP/IMAGE/IGNORE=INTERLOCK" instead. This is NOT true. By including "/IGNORE:INTERLOCK", you are specifically telling BACKUP to ignore the protective mechanisms that are there to ensure file consistency. The rest of this message is "more than you want to know" about the details of backing up "live" systems. Unless you have continuously-running applications with irreplacable data files, you probably won't care about it. If no user programs have files open for write, an on-line backup of a disk is a safe procedure - while VMS does have files open for write, they either don't matter to the backup (e.g., page files) or are virtually certain to remain consistent (e.g., SYSUAF). If you use BACKUP/IGNORE:INTERLOCK, what you end up with on your BACKUP tape may be inconsistent at the application level (i.e., if the application maintains multiple files, or multiple records within a file, that have to be consistent with each other, BACKUP may save a partially-updated set of data). It can even be inconsitent at the RMS level: If you catch an indexed file in the middle of a bucket split, you may not even be able to read the file with RMS after you restore it. It IS possible to write applications that can be told: "Put your files into a consistent state and do nothing until I tell you to go ahead". (One way to do this is to use blocking AST's.) While the files are in a consistent state, they can be backed up safely. HOWEVER, this requires (a) non-trivial programming effort; (b) that such application "pauses" be acceptable in the particular environment. (In some on-line transaction processing environments, they may not be. Backups in such environments are VERY difficult to do.) BACKUP/IGNORE:INTERLOCK will PROBABLY work MOST of the time. Unfortunately, we all know that if you do such backups every day for 3 years, the one time you need to restore the data will be the one time you caught the files in an inconsistent state. A common misconception is that you can do backups of "live" files by using disk shadowing: Put a disk in the shadow set, wait for it to be brought up to the current state of the rest of the set, the pull it from the shadow set. This won't work either, for exactly the same reason that BACKUP can fail: Without some coordination with the applications involved, there is no reason to believe that there is ANY time while the application is running at which the actual data on the disk is consistent. Again, MOST of the time, it MAY work, but.... The only complete solution is provided by journaling. Not cheap, but appro- priate - essential! - in some situations. -- Jerry ------