[Info-vax] OpenVMS x64 Atom project

[Jan-Erik Söderholm]

Den 2021-06-06 kl. 17:36, skrev Arne Vajhøj:
> On 6/6/2021 2:55 AM, Jan-Erik Söderholm wrote:
>> Den 2021-06-06 kl. 01:55, skrev Arne Vajhøj:
>>> On 6/5/2021 7:28 AM, Phillip Helbig (undress to reply) wrote:
>>>> In article <mn.2aa97e56e8d0753c.104627 at invalid.skynet.be>, Marc Van Dyck
>>>> <marc.gr.vandyck at invalid.skynet.be> writes:
>>>>>> One of the ransom cases I've cleaned up after some years ago had the
>>>>>> perpetrator silently corrupt multiple backups over time, deeper than the
>>>>>> organization's backup rotation schedule. The perpetrator then 
>>>>>> ransomed the
>>>>>> only remaining good copy of the organization's databases. In recent 
>>>>>> ransom
>>>>>> attacks on other platforms, the attackers have been active in the target
>>>>>> organization's networks for weeks and months, too.
>>>>>>
>>>>> I suppose that people in this organization never tried restores ? Doing
>>>>> regular restores to ensure the integrity of your backups is one of the
>>>>> major recommendations, isn't it ?
>>>>
>>>> Yes, there is little point in doing a backup if you don't test the
>>>> restore.  But imagine, say, a database of several hundred terabytes.
>>>> Even if you can restore it, you can't necessarily tell if the data are
>>>> somehow corrupt.  Yes, checksums and so on will catch some things, but
>>>> not all.
>>>
>>> Traditional BACKUP only works good on a system with no activity.
>>> BACKUP/IGNORE=INTERLOCK does not solve the problem.
>>>
>>> To get a consistent backup of a large database, without significant
>>> downtime, then one need a snapshot capability where updates after
>>> time T does not change what is being backed up.
>>>
>>> I believe modern storage systems can do that easily. Even though
>>> I do not know much about the details - last time I was responsible
>>> for backups then DAT tapes was cool.
>>
>> You let the database tools handle the database backup and then use
>> your regular filesystem tools to backup the "database backup".
>>
>> $!
>> $ RMU/BACKUP/ONLINE/LOG/extend=65535   <DB-ROOT>  xxx.RBF
>> %RMU-I-QUIETPT, waiting for database quiet point at  6-JUN-2021 00:02:08.26
>> %RMU-I-RELQUIETPT, Database quiet point lock has been released at 
>> 6-JUN-2021 00:02:08.28
>> %RMU-I-BCKTXT_00, Backed up root file xxx
>> %RMU-I-BCKTXT_02, Starting full backup of storage area (xxx)   at 
>> 6-JUN-2021 00:02:08.30
>> %RMU-I-BCKTXT_12, Completed full backup of storage area (xxx)  at 
>> 6-JUN-2021 00:05:04.72
>> %RMU-I-BCKTXT_02, Starting full backup of storage area (yyy)   at 
>> 6-JUN-2021 00:05:04.72
>> %RMU-I-BCKTXT_12, Completed full backup of storage area (yyy)  at 
>> 6-JUN-2021 00:06:53.49
>> %RMU-I-COMPLETED, BACKUP operation completed at  6-JUN-2021 00:06:53.53
>> $!
>>
>> Then approx an hour later ABC runs:
>>
>> Archive Backup Client for TSM on OpenVMS, Version V4.2.0.9
>> Copyright 1996-2010, Storage Solutions Specialists, Inc.
>> %ABC-I-SCNPASS, 01:43:47.19 Scanning file system for backup candidates
>> %ABC-S-BCKOK, saved xxx.RBF
>>
>> ABC is used very much as BACKUP with similar switches but
>> stores the backups on the central IBM TSM backup system.
>>
>> Now, this is not a "large" database, the RBF file is 17 M records.
>> On a "large" DB you need to do some other steps with incremental backups
>> or maybe selective backups, if not all your data is critical or not
>> updated. But RMU has the tools and options to do that.
> 
> I believe that is a common model.
> 
> But the rule is still that either the database will be unavailable
> for significant time or one need a snapshot capability where updates
> can be done but the backup sees the snapshot data at the time of the
> snapshot.
> 
> Storage or file system or database - the basic problem is the same.
> 
> Arne
> 


Yes. Rdb solves that using a "quiet point". As can be seen from the log
file above, that took 2 sec (freezing and waiting for active transactions
to finish). EFter that 2 sec delay, all update activity are back to normal
while the backup continues to run. The data backed up is the data that
was there at the point in time of the "quiet point lock release".

And any "snapshot" data is only saved to the "snapshot file" in the case
that some process request to update it. If not, there is no reason to
copy any data, of course. 99% of the database will be untouched during
the backup and thus not copied to the snapshot file.

So most of the data backed up is "real" data, not snapshot data.