[Info-vax] File Systems

[Stephen Hoffman]

On 2015-03-06 14:08:36 +0000, Jan-Erik Soderholm said:

> Stephen Hoffman skrev den 2015-03-06 14:39:
>> On 2015-03-06 03:22:14 +0000, JF Mezei said:
>> 
>>> On 15-03-05 14:46, Stephen Hoffman wrote:
>>> 
>>>> Or consistent, continuous, online backups,
>>> 
>>> How about using volume shadowing where one member is a special member 
>>> with differeent low level driver and its role is just to receive all 
>>> writes and update a "backup save set" in real time ?
>> 
>> This can be viewed as is a way to push the equivalent of a BACKUP 
>> /IGNORE=INTERLOCK "backup" down closer to the storage controller level, 
>> or a way to push a (bad) storage-level backup up into HBVS.
>> 
>> Applications almost invariably use more than one disk, so you'll have 
>> to capture and coordinate the I/O across all of the storage devices the 
>> application(s) use....
> 
> Yes, this will be hard for any backup on regualr files where there is 
> no syncronisation over the whole filesystem.
> 
> If this is a real concern it might be better to store your data that 
> must have consistent backups in a database.

True, though not all databases provide for consistent backups and 
associated tools, and not all applications that use databases — those 
databases that do have integrated backup tools — can be restored 
consistently — the database is certainly a core part of the data 
archival activities, but having some idea of the transaction contents 
is still necessary.   Some applications still necessarily store data 
outside the database — usernames or the creation of DCL command verbs, 
image files, cached or JIT'd code or cached data or generated DCL 
command procedures, etc., can all exist outside of the backup-protected 
transactional database.   But yes, if it's all in a 
transaction-protected integrated-backup database, then all you have to 
do is coordinate with the primary BACKUP operations, verify that the 
backups have run[1], and occasionally test your recovery.

Existing databases including SYSUAF and RIGHTSLIST, and the queue 
manager, and various other active OpenVMS data files, as well as a 
variety of other applications that use RMS files, do not presently have 
that option.   This short of retrofitting RMS journaling, or of using 
offline BACKUP — standalone BACKUP, in OpenVMS VAX terms — to get 
consistent and complete copies of the data.

Of course just adding the database or just using the database still 
does not get consistent whole-disk backups, either.  OS X Time Machine 
performs a database export of certain pre-configured databases during 
its operations, for instance, and then backs up the export to the 
archives.  The recovery involves restoring the export and then 
reloading the databases from that backup archives, as well.  OpenVMS 
does not have even a generic disk backup mechanism, leaving the user to 
perform manual BACKUP commands, or to create and test site-local BACKUP 
and database-specific export procedures.

> Rdb have never had any problem with this, either regarding having 
> transaction consistent online backups or that the data is on multiple 
> physical disks. Your data (tables) are always consistend over all 
> tables and all disk volumes.

Rdb would be associated with the RMU /BACKUP command mentioned later in 
that reply.   Rdb is almost certainly not going to be added into the 
base distro (again), but it'd be nice to have a viable database or two 
either included in or easily available for the base VMS distro; 
PostgreSQL or SQLite or otherwise.  Most operating systems now include 
one or more databases, after all.  It'd also be nice to have a way for 
RMS — far and away the most common database used on VMS — to provide 
for a consistent and application- and BACKUP-coordinated access for 
backups, too.

————
[1]Recently discovered an errant database backup procedure that was 
generating runt-sized backup export files secondary to a database 
access failure, and the runt database export files had completely 
fooled the secondary database backup verification tools into assuming 
that the database backup was actually running.  The secondary database 
backup verification tool found those current non-zero-sized runt files 
with the expected file creation dates and with contents that were 
consistent with a database export and thus the tool passed the 
secondary tests and didn't notify the staff, but there were no backups. 
 "That's odd.  Why are these backup files so much smaller than the 
database?"



-- 
Pure Personal Opinion | HoffmanLabs LLC