How SnapManager retains backups on the local storage
Suggest changes
PDFs
SnapManager enables you to create backups that meet retention policies, which specify how many successful backups on local storage should be retained. You can specify the number of successful backups that should be retained in the profile for a given database.
You can create backups for the following:
-
10 days of daily backups on primary storage
-
2 months of monthly backups on primary storage
-
7 days of daily backups on secondary storage
-
4 weeks of weekly backups on secondary storage
-
6 months of monthly backups on secondary storage
For each profile in SnapManager, you can change the values for the following nonlimited retention classes:
-
Hourly
-
Daily
-
Weekly
-
Monthly
SnapManager determines whether a backup should be retained by considering both the retention count (for example, 15 backups) and the retention duration (for example, 10 days of daily backups). A backup expires when its age exceeds the retention duration set for its retention class or the number of backups exceeds the retention count. For example, if the backup count is 15 (SnapManager has taken 15 successful backups) and the duration requirement is set for 10 days of daily backups, the five oldest successful eligible backups expire.
After a backup expires, SnapManager either frees or deletes the expired backup. SnapManager always retains the last backup taken.
SnapManager counts only the number of successful backups for the retention count and does not consider the following:
| Backups not included in the retention count | Additional details |
|---|---|
Failed backups |
SnapManager retains the information about successful and unsuccessful backups. Although unsuccessful backups require only minimal space in the repository, you might want to delete them. Unsuccessful backups remain in the repository until you delete them. |
Backups designated to be retained on an unlimited basis or backups for a different retention class |
SnapManager does not delete backups designated to be retained on an unlimited basis. Additionally, SnapManager considers only those backups in the same retention class (for example, SnapManager considers only the hourly backups for the hourly retention count). |
Backups mounted from local storage |
When Snapshot copies are mounted, they are also cloned and so are not considered eligible for retention. SnapManager cannot delete the Snapshot copies if they are cloned. |
Backups that are used to create a clone on local storage |
SnapManager retains all the backups that are used to create clones, but does not consider them for the backup retention count. |
SnapManager provides a default retention count and duration for each retention class. For example, for the hourly retention class count, SnapManager, by default, retains four hourly backups. You can override these defaults and set the values when creating or updating the profile or change the default values for retention count and duration in the smsap.config file.
When local backups expire based on their retention policy, the backups are deleted.
In an archivelog-only backup operation, SnapManager does not archive the redo log files, unlike in the online database backup process. You must add a pretask script to archive the redo log files before performing the archivelog-only backup operation. The pretask script must run the alter system switch logfile command.
The following example shows the actions that SnapManager takes on various types of backups, based on a three-daily-backups retention policy (with the count set to retain 3):
| Backup date | Status | Retention policy action taken | Explanation |
|---|---|---|---|
5/10 |
Successful |
Keep |
This is the most recent successful backup, so it will be kept. |
5/9 |
Successful, cloned |
Skip |
SnapManager does not consider backups used for cloning in the retention policy count. This backup is omitted from the count of successful backups. |
5/8 |
Successful, mounted |
Skip |
SnapManager does not consider mounted backups in the retention policy count. This backup is omitted from the count of successful backups. |
5/7 |
Failed |
Skip |
Failed backups are not counted. |
5/5 |
Successful |
Keep |
SnapManager keeps this second successful daily backup. |
5/3 |
Successful |
Keep |
SnapManager keeps this third successful daily backup. |
5/2 |
Successful |
Delete |
SnapManager counts this successful backup, but after SnapManager reaches three successful daily backups, this backup is deleted. |
Related information