[Info-vax] OpenVMS x64 Atom project

[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