Retention Policy
This chapter describes the retention policy for the new backup format. For the information about the legacy backup retention policy refer to the following article.
This chapter covers the following topics:
- Before You Begin
- How to Select Optimal Combination of Schedule and Retention Policy
- Examples
- Edit Retention Policy
It's crucial to understand that schedule and retention are interrelated and have a mutual influence. Together, they determine the storage duration for backups and ensure the desired number of valid restore points are maintained in the backup storage. This configuration includes the following aspects:
- Backup Frequency: This is determined by the Full Backup and Incremental Backup schedules. Each backup run creates a restore point that serves as a recovery option. The backup frequency directly impacts the number of restore points stored during this period. More frequent backups result in more restore points, which affects storage consumption.
- Retention Period: By setting a retention period, you specify for how long backups should be retained.
This article aims to clarify the basics of retention policy and offer an optimal strategy for configuring backup schedules and retention periods.
Before You Begin
All terms used in this article are explained in this article. Read this article before proceeding.
CSelect Optimal Combination of Schedule and Retention Policy
Key Considerations for Determining Optimal Backup Schedule and Retention Policy
To configure an efficient and reliable backup strategy, several important decisions need to be made:
- Required period to store restore points: Depending on your incremental backup frequency, it's essential to determine for how long you want to retain restore points created by incremental backups. This decision defines your "Basic" Retention period, during which every restore point created is accessible.
- Frequency of full backups: Retention police cannot work without scheduled full backups. Understanding that MSP360 utilizes a generation-based approach to storing backups, where each generation is a set of a full and following incremental backups, is crucial. The term "generation" is closely linked to your full backup frequency. Each full backup completes a generation and initiates a new one. Frequency of backup runs: Your incremental backup frequency determines the frequency of restore points you can have during the basic retention period.
- Number of generations to store: Deciding on the number of generations (full + incremental chains) to retain in storage is crucial, as each generation multiplies storage consumption compared to the source data size. To calculate this, simply count the number of full backups scheduled during the specified retention period. This will provide an approximate idea of the number of full backups and the storage consumption based on the source data size.
- Requirement for longer retention for full backups (GFS): In certain scenarios, there may be a need to retain selected full backups for an extended period (weeks, months, or years) without storing the rest of restore points created using incremental backups. In such cases, it 's necessary to define the frequency and keeping period for these full backups. This is configured separately from the "Basic" Retention period and is also influenced by your full backup schedule.
Let's illustrate these concepts with examples.
Examples
How to Estimate Backup Size in Examples
The size of full backup can be estimated depending on selected content to backup.
The size of incremental backups can only be estimated after the first incremental backups were complete. The size of every incremental backup depends on the following factors:
- how many changes were made between two incremental backup runs
- frequency of incremental backups
- retention settings.
You can estimate the size of incremental backups in your environment after the first incremental backups were complete.
The number of full and incremental backups will be specified in examples below depending on selected schedule / retention.
Example 1. Forever Forward Incremental (Backup Storage WITHOUT Minimum Storage Duration Policy)
Parameter | Value |
---|---|
Required period to store restore points | 1 month |
Number of backup generations to store | 1 generation |
Frequency of full backups | ❌ |
Frequency of backup runs | Every day |
Requirement for longer retention for full backups (GFS) | ❌ |
To meet your requirements, you should select to keep backups for 1 month.
First generation was created on November 1 ( 2024) with full backup. This full backup can only be purged after 1 month expires.
On December 2 (day 32), at the end of the backup run, full backup from November 2 can be purged, but backup data of this backup is merged with backup data of incremental backup from November 2 to create synthetic full backup from November 2. The backup storage now contains 1 full backup (November 2) and up to 29 incrementals.
Example 2: Forever Forward Incremental (Backup Storage WITH Minimum Storage Duration Policy (30 Days))
Parameter | Value |
---|---|
Required period to store restore points | 1 month |
Number of backup generations to store | 1 generation |
Frequency of full backups | ❌ |
Frequency of backup runs | Every day |
Requirement for longer retention for full backups (GFS) | ❌ |
To meet your requirements, you should select to keep backups for 1 month. You should realize that if you want to keep backups for 1 month and meet the requirements of minimal storage duration policy, the Intelligent Retention must be enabled to complete your estimations. Intelligent retention will work for you to ensure you will meet the early duration fee requirements.
First generation was created on November 1 ( 2024) with full backup. This full backup can only be purged after 30 days expire.
On December 3 (day 33), at the end of the backup run, full backup from November 1 can be purged (30 days have expired), but backup data of this backup is merged with backup data of incremental backup from November 2 (30 days have expired) to create synthetic full backup from November 2. The backup storage now contains 1 full backup (November 2) and up to 32 incrementals.
On December 4 (day 34), at the end of the backup run, the backup storage now contains 1 full backup (November 2) and up to 31 incrementals. Full backup from November 2 cannot be purged (30 days have not expired). The backup storage now contains 1 full backup (November 2) and up to 33 incrementals.
On January 1 (day 62) at the end of the backup run, full backup from November 2 can be purged (30 days have expired), but backup data of this backup is merged with backup data of incremental backups from November 3 - December 2 (30 days have expired for them) to create synthetic full backup from December 2.
The backup storage now contains 1 full backup (December 2) and up to 30 incrementals.
Example 3. Recurring Schedule
Parameter | Value |
---|---|
Required period to store restore points | 3 months |
Number of backup generations to store | 3 generations |
Frequency of full backups | Monthly, 1 full backup in a month |
Frequency of backup runs | Every working day |
Requirement for longer retention for full backups (GFS) | ❌ |
To meet your requirements, you should select to keep backups for 2 months. This is not a mistake. The oldest generation will only be purged when 2 months expired for the last restore point created on base of the last incremental backup of the oldest generation. This really happens when 3 months expire.
First generation was created on November 1 with full backup. Last restore point of this generation was created on November 30 and expires after 2 months (retention period). Then, this generation can only be purged on February 1, because it can only be deleted after the retention period expires for the last restore point of the generation.
On February 1 (day 92), at the backup run completion, the oldest generation can be purged. The backup storage now contains 3 full backups (December 1, January 1 , and February 1) and up to 44 incrementals.
Example 4: Recurring Schedule + GFS
Parameter | Value |
---|---|
Required period to store restore points | 3 years |
Number of backup generations to store | 36 generations |
Frequency of full backups | Monthly, 1 full backup in a month |
Frequency of backup runs | Every working day |
Requirement for longer retention for full backups (GFS) | ✔️ |
To meet your requirements, you should select to keep backups for 2 months and enable GFS with monthly full backups kept for 36 months. The backup run that is not selected for GFS will only be purged when 2 months expired for the last restore point of the previous generation containing this backup run. The backup runs of the current generation can never be purged.
Read more about the GFS policy in the GFS section.
First generation was created on November 1 ( 2024) with full backup. This full backup will automatically be selected as GFS monthly full backup and can only be purged after 3 years (36 months expire). Last restore point of this generation was created on November 30 and expires after 2 months (retention period). Then, all restore points based on incremental backup from this generation can be purged on February 1, after the retention period expires for the last restore point of the generation.
On February 1 (day 92), at the backup run completion, all restore points based on incremental backup from the generation November 1-30 can be purged. Full backup created on November 1 remains on backup storage. The backup storage now contains 4 full backups (November 1, December 1, January 1 , and February 1) and up to 44 incrementals.
On November 1, 2027 the GFS retention period expires for monthly full backup from November 1, 2024 and this backup can be purged. The backup storage now contains 36 full backups and up to 44 incrementals.
Edit Retention Policy
To modify the retention policy for the backup plan, proceed as follows:
- Open the Management Console.
- In the Computers menu find the required computer
- Click the Configure icon.
- Find the required plan, expand it, then click Edit.
In the backup wizard, switch to the Retention Policy step. Consider, in case you change the Retention policy with enabled GFS, Object Lock or Forever Forward Incremental, you can change the retention only for subsequent backups, not for existing ones.
Make the required changes.
Click Save.