File Retention Lock and Snapshot Retention Lock are great new features on ZFSSA that can help protect your backups from deletion and help you meet regulatory requirements. Whether it be an accidental deletion or a bad actor attempting to corrupt your backups they are protected.
In this post I am going to walk through how to implement File Retention and Snapshot Retention together to protect an RMAN incremental merge backup from being deleted .
Why do I need both?
The first question you might have is why do I need both File Retention and Snapshot Retention to protect my backups ? RMAN incremental merge backups consists of 3 types of backup pieces.
FILE IMAGE COPIES - Each day when the backup job is executed the same image copy of each datafile file is updated by recovering the datafile with an incremental backup. This moves the image copy of each datafile forward one day using the changed blocks from the incremental backup. The backup files containing the image copy of the datafiles needs to be updatable by RMAN.
INCREMENTAL BACKUP - Each day a new incremental backup (differential) is taken. This incremental backup contains the blocks that changed in the database files since the previous incremental backup. Once created this file does not change.
ARCHIVE LOG BACKUPS - Multiple times a day, archive log backups (also known as log sweeps) are taken. These backup files contain the change records for the database and do not change once written.
How to leverage both retention types
SNAPSHOT RETENTION can be used to create a periodic restorable copy of a share/project by saving the unique blocks as of the "snapshot" time a new snapshot is taken. Each of these periodic snapshots can be scheduled on a regular basis. With snapshot retention, the snapshots are locked from being deleted, and the schedule itself is locked to prevent tampering with the snapshots. This is perfect for ensuring we have a restorable copy of the datafile images each time they are updated by RMAN.
FILE RETENTION can be used to lock both the incremental backups and the archive log backups. Both types of backup files do not change once created and should be locked to prevent removal or tampering with for the retention period.
How do I implement this ?
First I am going create a new project for my backups named "DBBACKUPS". Of course you could create 2 different projects.
Within this project I am going to create 2 shares with different retention settings.
FULLBACKUP - Snapshot retention share
My image copy backups are going to a share that is protected with snapshot retention. The documentation on where to start with snapshot retention can be found here.
In the example below I am keeping 5 days of snapshots, and I am locking the most recent 3 days of snapshots. This configuration will ensure that I have locked image copies of my database files for the last 3 days.
NOTE: Snapshots only contain the unique blocks since the last snapshot, but still provide a FULL copy of each datafile. The storage used to keep each snapshots is similar to the storage needed for each incremental backup.
DAILYBACKUPS - File Retention share
My incremental backups and archivelog backups are going to a share with File Retention. The files (backup pieces) stored on this share will be locked from being modified or deleted. The documentation on where to start with File Retention can be found here.
NOTE: I chose the "Privileged override" file retention policy. I could have chosen "Mandatory" file retention policy if I wanted to lock down the backup pieces even further.
In the example below I am retaining all files for 6 days.
DAILY BACKUP SCRIPT
Below is the daily backup script I am using to perform the incremental backup, and the recovery of the image copy datafiles with the changed blocks. You can see that I am allocating channels to "/fullbackup" which is the share configured with Snapshot Retention, and the image copy backups are going to this share. The incremental backups are going to "/dailybackups" which is protected with File Retention.
run {
ALLOCATE CHANNEL Z1 TYPE DISK format '/fullbackup/radb/DATA_%N_%f.dbf';
ALLOCATE CHANNEL Z2 TYPE DISK format '/fullbackup/radb/DATA_%N_%f.dbf';
ALLOCATE CHANNEL Z3 TYPE DISK format '/fullbackup/radb/DATA_%N_%f.dbf';
ALLOCATE CHANNEL Z4 TYPE DISK format '/fullbackup/radb/DATA_%N_%f.dbf';
ALLOCATE CHANNEL Z5 TYPE DISK format '/fullbackup/radb/DATA_%N_%f.dbf';
ALLOCATE CHANNEL Z6 TYPE DISK format '/fullbackup/radb/DATA_%N_%f.dbf';
backup
section size 32G
incremental level 1
for recover of copy with tag 'DEMODBTEST' database FORMAT='/dailybackups/radb/FRA_%d_%T_%U.bkp';
recover copy of database with tag 'DEMODBTEST' ;
RELEASE CHANNEL Z1;
RELEASE CHANNEL Z2;
RELEASE CHANNEL Z3;
RELEASE CHANNEL Z4;
RELEASE CHANNEL Z5;
RELEASE CHANNEL Z6;
}
ARCHIVELOG BACKUP SCRIPT
Below is the log sweep script that will perform the periodic backup of archive logs and send them to the "/dailybackups" share which has File Retention configured.
run {
ALLOCATE CHANNEL Z1 TYPE DISK format '/dailybackups/radb/ARCH_%U.bkup';
ALLOCATE CHANNEL Z2 TYPE DISK format '/dailybackups/radb/ARCH_%U.bkup';
ALLOCATE CHANNEL Z3 TYPE DISK format '/dailybackups/radb/ARCH_%U.bkup';
ALLOCATE CHANNEL Z4 TYPE DISK format '/dailybackups/radb/ARCH_%U.bkup';
ALLOCATE CHANNEL Z5 TYPE DISK format '/dailybackups/radb/ARCH_%U.bkup';
ALLOCATE CHANNEL Z6 TYPE DISK format '/dailybackups/radb/ARCH_%U.bkup';
backup
section size 32G
filesperset 32
archivelog all;
RELEASE CHANNEL Z1;
RELEASE CHANNEL Z2;
RELEASE CHANNEL Z3;
RELEASE CHANNEL Z4;
RELEASE CHANNEL Z5;
RELEASE CHANNEL Z6;
}
RESULT:
This strategy will ensure that I have 5 days of untouched full backups available for recovery. It also ensures that I have 6 days of untouched archive logs, and incremental backups that can be applied if necessary. This will protect my RMAN incremental merge backups using a combination of Snapshot Retention for backup pieces that need to be updated, and File Retention for backup pieces that will not change.
No comments:
Post a Comment