As database professionals, we’re the custodians of our organisation’s data. In the event of a data-related issue, we’re usually one of the first on the scene.
Over the last few years, we’ve seen an increasing number of ransomware attacks. Ransomware has been headline news around the globe. It’s impacting all industries, with seemingly no target off-limits.
With this in mind, we need to constantly review and reduce our exposure to malware and other external and internal threats. We need to adopt a multilevel approach to data protection and implement a resiliency architecture.. Think “defence-in-depth.”
Defence-in-Depth
During database-server security reviews, we need to consider how to make the malware or unauthorised intruder’s job as difficult as possible. We need to maintain the latest operating system and application patches. We should also explore hardening our servers by, for example:
- Avoiding installing unnecessary applications
- Running only required services
- Using non-default ports
- Not advertising operating system and version information
- Locking down access with correct file permissions and ownership
- Implementing a security information and event management (SIEM) solution such as Splunk
Additionally, include backups when considering your database servers.
- Off-Array Backups: Wherever possible, store database backups off the primary storage array to ensure the storage platform isn’t a single point of failure or risk. A popular approach is to present a shared filesystem to all database servers delivered from an NFS server such as Pure Storage® FlashBlade®.
- Hide Backup Locations: Another security measure is to hide backup locations and only mount the NFS filesystems when accessed with autofs, also known as automounter. You can use automounter with Oracle Recovery Manager (RMAN) to mount the NFS filesystems when required. You can also use it to unmount the filesystem automatically when it’s no longer needed.
- Snapshot RMAN Backups: Storage snapshots provide a simple way to protect Oracle RMAN backups from accidental or malicious deletion. Oracle RMAN jobs and backup processes will continue to read, write, and delete files in the backup location. However, having a read-only snapshot will stop any malware or DBA from accidentally or maliciously deleting essential backup files.
- Replicate Snapshots with SafeMode: To protect against loss of hall, data centre, or site data, also consider snapshot replication to ensure backups are available in a different location if needed.
The security methods outlined above provide good protection from many host-based issues. But what if our storage credentials are compromised and storage snapshots are deleted directly on the array?
Pure SafeMode™ snapshots further enhance data protection by prohibiting the eradication (deletion) of snapshots without engaging with Support.
Protecting RMAN Backups
I developed a Python script to automate the process of taking snapshots and optional replication to a secondary array. I can call the script from my RMAN backup scripts.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
$ python3 pureTakeFBsnapshot.py -h Usage: pureTakeFBsnapshot.py [options] This application has been developed using Pure Storage v1.12 RESTful Web Service interfaces. It was developed and tested using Python 3.9.5. Options: --version show program's version number and exit -h, --help show this help message and exit -d, --debug Debug [default: False] -f FS, --filesystem=FS FlashBlade File System -r FLASHBLADEREP, --replicant=FLASHBLADEREP FlashBlade Replicant array -s FLASHBLADE, --server=FLASHBLADE FlashBlade array -t API_TOKEN, --token=API_TOKEN Pure API Token -S SUFFIX, --suffix=SUFFIX File system snapshot suffix -v, --verbose Verbose [default: False] |
In the example below, I’ve taken a snapshot, provided a suffix, and initiated replication to another array.
Now that we have a read-only snapshot of the RMAN backup, we’re protected against accidental deletion, ransomware encryption, and malicious destruction of the database backups. Plus, SafeMode provides additional protection against a rogue storage administrator or compromised storage platform.
Cataloging Backups in the Recovery Catalog
The Catalog start with Oracle RMAN feature provides the ability to manually catalog backups in the recovery catalog. We can use it to include the snapshot location using catalog start with <mount point/.snapshot/file filesystem.suffix> RMAN> catalog start with ‘/mnt/orabkup/DEMO/.snapshot/z-oracle_orabkup.08-JUN-2021-093552’ noprompt;
RMAN Validate
Once you’ve registered the RMAN backup snapshot location, use RESTORE… VALIDATE to confirm that backups required to restore the database are present, readable, and not corrupted:
RMAN> restore database validate;
RMAN Restore
The Oracle RMAN RESTORE command can now use the NFS snapshot backup location to restore, validate, or preview RMAN backups.
Summary
In this blog post, I’ve shared a few ideas on how to use your storage platform to provide greater protection to critical database backups. In addition, I’ve demonstrated how Oracle RMAN can work with NFS read-only snapshot directories for database recoveries, protecting against accidental deletion, ransomware encryption, and malicious destruction of backups and snapshots.
Finally, remember Schrodinger’s Backup and keep testing your Oracle backups.
