[Info-vax] OpenVMS x64 Atom project

[Jan-Erik Söderholm]

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.
> 
> Arne
> 
> 

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.