> From: Jeremy Begg <[email protected]> > ... > Hi Zane, > >> Thanks Jeremy, if I'm understanding what you're saying correctly, I'm going >> to feel really stupid. Am I correct in reading this that I don't have to >> boot into Standalone Backup, in order to backup the system disk? I've >> thought that was a requirement for cloning a drive for well over 20 years. > > Standalone Backup is not required. It's recommended for use when you need to > be 100% certain that no file at all will change during the backup (e.g. to > make an archival copy for the auditor) but for day-to-day use a $ > BACKUP/IMAGE/IGNORE=INTERLOCK will work fine. (Thanks to Mark for reminding > us about /IGNORE=INTERLOCK>) > > Of course, it's good to have as little running as possible at the time.
BACKUP /ALLOW=DATA_INCONSISTENCY? Yeah. My favorite. The results of that can be somewhat unpredictable with any data disk or with any system disk, and those backups of system disks can typically be made bootable again. Usually. I've encountered problems with the queue manager with the results of a restoration of a BACKUP /ALLOW=DATA_INCONSISTENCIES, and the queue manager can need a reset. Usual symptom of this mess is a startup that wedges in the queue-related processing, followed by some INITIALIZE /QUEUE or related commands. Application I/O activity is utterly indeterminate though—apps with any multi-file writes will inevitably be corrupt whenever the associated files cross the BACKUP file scan, and multi-part writes within a single file can also be problematic but those do have a smaller window. For an example of multi-file operations, consider how the entries in SYSUAF and RIGHTSLIST are (usually) kept in synch. An account creation where the scan be between those two files will record inconsistent data. Yes, that's a pretty rarely-triggered example, but some apps routinely update multiple files as part of one transaction, and some of those apps can be far more write-prolific. The use of transaction processing synchronization for multi-part writes won't help apps here either, as BACKUP /ALLOW=DATA_INCONSISTENCIES is oblivious to the state of the DECdtm transactions. BACKUP /ALLOW=DATA_INCONSISTENCIES also disables some of the processing around cluster file accesses, which means there won't (reliably) be diagnostics generated for some cases of file access collisions. And if there are databases around, all bets are off. Some apps and some databases can be far more aggressive around caching data. Officially? Booting and using some other system disk on any of the architectures, or booting standalone BACKUP when on OpenVMS VAX. For more general system disk backup strategies, copy the couple-dozen cluster-shared files (mostly referenced in SYLOGICALS.TEMPLATE) elsewhere, back that up with CONVERT /SHARE or equivalent, and don't worry so much about backing up the system disks as frequently as backing up the data disks. System disks usually can be restored from distros, and—other than the couple-dozen files—don't change all that often, so system disk backups can be made after configuration changes or installs, and then rather less often. The few-dozen files, yes, those can need more frequent backups. (And for some of these cases, put the local SYSTARTUP_VMS and SYLOGICALS and related into the same area with the couple-dozen shared files, with stubs calling those files left in the standard locations in the system directories.) As for BACKUP /ALLOW=DATA_INCONSISTENCIES, it's your data... Hoff Stephen Hoffman - HoffmanLabs LLC _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
