May 23, 2022
A system can always be replaced, but the files and objects that comprise the application and the data that makes it useful can fall victim to all sorts of decay, neglect, or abuse in a modern system. And that is why we did backups to tape subsystems, or even tape libraries and then virtual tape libraries based on disk drives for so many years. And for those who cannot afford to have downtime or lost data, the IBM i base has been fortunate to have some of the best high availability clustering ever invented.
With ransomware and malware attacks on the rise, it is more important than ever to create immutable copies of data – a snapshot of the information in the machine that cannot be tampered with. This capability is built into IBM’s FlashSystem arrays, and is increasingly used by IBM i customers to create snapshots of their data that can be used in the event of an attack or some other kind of data corrupting event.
We have talked to a lot of IBM i customers who are interested in or are making immutable copies using their FlashSystem arrays, and they think it is fine to do an immutable copy of the system every hour and stack them up. And if they get hacked and someone, for instance, tries to encrypt their archived data – a common attack method these days – then the practice is to keep going back into the archive of immutable copies by hand until one of them works, until one of the copies is not infected.
We don’t like that approach. And that is why we have come up with a safe guarded copy methodology that we call CopyAssure. With CopyAssure, we are perfectly happy that customers make lots of immutable copies of their key data. But we believe that as you make these immutable copies, you have to perform the extra set of steps and make sure that this immutable copy is valid and can be put back onto a recovered system in the event of a disaster or an attack.
This means every immutable that gets taken is validated at the time it was taken, automatically made available, added to a partition and the IBM i OS booted up and then the integrity of the database and…