How SnapManager retains backups on the local storage

Contributors Download PDF of this page

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.

Backups that are cloned or mounted on secondary storage and that use the mirror protection policy

If SnapManager deletes the Snapshot copies for the backup on the primary storage resource and the Snapshot copies are mirrored, the next backup to the secondary storage will fail.

When you free a backup from its primary storage resources, the primary resources (Snapshot copies) used by the backup are destroyed, but the backup metadata is still available. SnapManager does not consider freed backups in 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 smo.config file.

Backups on primary storage can be protected by backing up to secondary storage. While SnapManager manages the retention and scheduling of backups on primary storage, the Protection Manager manages the retention and scheduling of backups on secondary storage.

When local backups expire based on their retention policy, they are either deleted or freed, depending on whether they are protected.

  • If they are protected, the local backups are freed. Their storage resources or Snapshot copies are deleted, but the backups remain in the SnapManager repository and are available for restoration from the secondary storage. You do not have to free backups (for example, with the backup free command). Backups are freed until the backup no longer exists on the secondary storage, and at that point, the backup is deleted.

  • If they are not protected, the local 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