Carbonite Support > Retention Policy Best Practice...

Retention Policy Best Practices

  • This article is for Windows only

A retention policy controls the period of time that a backup is kept. Carbonite Safe Server Backup allows users to choose their own retention policy. You have the ability to set retention to meet your needs.

It is important to think through the ramifications of your chosen retention policy. If you set your retention policy too short, you may find yourself unprotected. If you set your retention policy too long, you may run out of space to store your backups.

This article outlines the best practices for retention policies and explains some of the common problems that occur when these best practices are not followed.

The sections below are collapsed. Please click the section title to open / close a particular section.

Best Practices

  • Always keep the default retention policy unless you have a good reason to change it.
    • The defaults represent our minimum recommendation. If you must change it, keep more, not less.
  • Never keep fewer than 2 backup cycles. The backups should cover at least 60 days.
    • If you keep only 1 cycle, or keep data for a short amount of time, you run the risk of data loss in situations where files become encrypted, corrupted, deleted, or otherwise damaged without your knowledge.
  • Always use cycle-based retention instead of time-based retention unless you have a good reason to change it.
    • Cycle-based retention is easier to understand, track, and manage.
    • Time-based retention can be confusing and is best used to archive data that must be kept for a specific length of time.
  • Always ensure that you have enough space to store your backups on both disk and cloud.
    • Backups will fail if you do not have enough space.
    • Try to keep at least 10% free space to account for data growth and fluctuations in backup size.

What is the Default Retention Policy?

By default, CSSB uses cycle-based retention. A backup cycle is defined as a full backup and all incremental and/or differential backups associated with the full backup. When using cycle-based retention, the oldest backup cycle will not be deleted until after the next full backup completes. This affects the amount of storage space you need.

The exact default retention policy is not the same for all backup types. However, the defaults always ensure that at least two backup cycles are kept and that those backup cycles cover at least 60 days.

It is a best practice to keep the default value unless you have a good reason to change it. If you must change it, keep more data, not less. Your risk of data loss is far higher if you keep only one backup cycle.

Why Should I Always Keep at Least Two Full Backup Cycles That Cover at Least 60 Days?

It can be dangerous to keep only one backup cycle, or to keep your backups for a very short period of time. Files can become damaged without your immediate knowledge. If they become damaged at the wrong time in your cycle, it's possible that the good files in your backup will be purged by retention, leaving you with only damaged files in your backups.

The various Crypto viruses, such as Cryptolocker, etc. are of special note. A Crypto virus can run silently for days or weeks while it encrypts your files. When it's done, it will ask you to pay to decrypt the files. At that point, you have two choices: pay the ransom, or restore the unencrypted files from before you were infected.

Imagine the following scenario:

  1. Your server becomes infected with a Crypto virus on Monday. It begins to encrypt your files, silently.
  2. You have a full backup scheduled to occur on Friday. The full backup is successful, but it's full of encrypted files.
  3. After the full backup is finished, the oldest backup cycle is deleted.
  4. On Saturday, the Crypto virus finishes its work. You receive a notice that your files are encrypted. The notice tells you that you can pay to decrypt your files.
  5. You now have a choice: pay the ransom or restore from a backup.

If you kept two or more backup cycles, you would be able to restore unencrypted files from the previous backup cycle, before the Crypto virus infected your server. Restoring after a Crypto virus is very easy with CSSB. However, if you had only kept one backup cycle, the previous backup cycle would have been deleted as per the retention policy. You cannot restore from a deleted backup. You would be in a very bad situation, because your only backup would be full of encrypted files.

Crypto viruses are not the only reason to keep at least two backup cycles. Deletion of data, corruption caused by failing hardware, and other problems can go a long time without notice. The more backup cycles you keep, the more time you have to notice these things and restore your data.

It is a best practice to keep at least two full backups at any given time. These backups should cover at least 60 days.

Why Should I Use Cycle-Based Retention Instead of Time-Based Retention?

For most customers, cycle-based retention is easier to understand. This Knowledge Base article describes how cycle-based retention works in more detail.

Time-based retention can be confusing. If time-based retention is chosen, there are overrides in place that make it act much like cycle based retention. For example, the Keep backup if a dependent backup exists override ensures that backups in a backup cycle are not deleted until all the backups in a cycle are ready for deletion. However, this can keep any individual backup run long past its supposed expiration date. You can read more about time-based retention and the retention overrides in the CSSB User Guide.

Due to the overrides, many customers find time-based retention to be confusing. CSSB does allow the overrides to be disabled, but doing so is not a best practice. You can lose the ability to restore some or all of your data if some backups in a backup cycle are deleted.

Time-based retention is thus best used when you need to archive a specific set of data for a specific set of time. For example, you may need to archive a financial statement for a specific length of time for legal reasons.

It is a best practice to use cycle-based retention unless you have a clear need to do otherwise.

How Much Storage Do I Need for My Backups?

Backups will fail if they do not have enough space on disk and/or the cloud. You must ensure that there is enough space for your backups to complete. In all cases, you will need enough space for the total size of each backup cycle times the number of cycles retained. In some cases, you will also need enough space for the next full backup to complete, because the oldest backup cycle will not be deleted until the next full backup is complete.

We cannot predict exactly the amount of space you'll need for any given backup or backup cycle. It depends on the amount of data you have, the type of data you have, and the amount of data that changes between backups.

However, most users find that the size of one backup cycle is similar to the next. They can say things like "my full backups are around 100GB in size." If you have established backups, you can make an educated prediction for the amount of space you will need.

Example scenario

  • Your full backups are 100GB, performed once a month.
  • Your incremental backups are 10GB on average, performed every day. For the purposes of this exercise, we will assume there are 30 days in the month.
  • Retention policy is set to 2 full backups.

Size of each complete backup cycle: 400GB

400GB = 100GB Full Backup + (10GB Incremental Backup * 30 days)

Minimum amount of space required on disk (all CSSB versions) and on the cloud (CSSB 5.1 or lower): 900GB

For all backups performed to disk and for cloud backups in CSSB 5.1 or lower, you must have enough space for each backup cycle plus enough space for the next full backup.

900GB = (400GB Backup Cycle * 2 Cycles Retained) + 100GB Next Full Backup

Minimum amount of space required on the cloud (CSSB 5.2 and higher): 800GB

In CSSB 5.2 or higher, the space for the next full backup is not required for backups to the cloud.

800GB = 400GB Backup Cycle * 2 Cycles Retained

In the example, we found the minimum amount of space required. You may find that your backups grow larger over time. This is common. In most environments, the amount of data grows over time. You may also find that your backup sizes fluctuate from time to time, because more data is created or changed than usual. You should keep at least 10% extra space to account for growth or unexpected fluctuations in backup size.

It is a best practice to ensure that you have enough space on disk and/or cloud to complete your backups. This includes at least 10% extra space on disk and cloud.