Backup Scheduling Best Practices

Last modified

Welcome

Thank you for choosing StorSimple!  This document (TR00005) serves to provide best practices for scheduling snapshots, Cloud Snapshot, and Cloud Clones. This document is written for appliance models 1010, 5010, and 7010 using software version 1.2 and either the appliance web GUI or the StorSimple Data Protection MMC snap-in.

This technical report is broken down into the following sections:

 

Overview

StorSimple Data Protection is a comprehensive solution for protecting data stored on StorSimple volumes using integrated storage within the appliance and the associated cloud storage services.  StorSimple provides three types of backup copies for your data:

  • Snapshots – Snapshots are point-in-time backup copies of volume(s) that are tiered between appliance storage and the cloud in the same way that regular volumes are tiered.  Snapshots are considered local backup copies and are kept for short periods of time
  • Cloud Snapshot – Cloud Snapshots are point-in-time backup copies of volume(s) that are stored in the cloud with primary volume data.  Although they are stored fully in the cloud, Cloud Snapshot data is co-resident with primary volume data.  Cloud Snapshots provide an off-site backup copy but are not truly-independent and do not protect against failure of an entire cloud region, and are analogous to a snapshot replicated to another storage array
  • Cloud Clones – Cloud Clones are point-in-time backup copies of volume(s) that are stored in the cloud separate from primary volume data.  Cloud Clones provide an off-site backup copy that is truly-independent, and are analogous to an off-site tape vault

Customers that are interested in building a data protection policy similar to that of existing infrastructure will use a combination of the three technologies described above.  These policies can be implemented either using the appliance web GUI (supporting Windows, VMware, Linux, and other environments), or, using the StorSimple Data Protection snap-in for the Microsoft Management Console (MMC) when installed on Microsoft Windows 2008 servers. 

It is important to note that the StorSimple Data Protection MMC snap-in provides application-consistent snapshots, leveraging the Microsoft Volume Shadow Copy Services (VSS) framework, whereas any policies implemented via the appliance web GUI will only provide crash consistency.  This document focuses specifically on the scheduling aspect of policies and does not examine the required consistency levels for any application.  In general, it is best to use the StorSimple Data Protection MMC when protecting data for Windows file servers, SharePoint, or Exchange, but these applications can be protected using policies created in the appliance web GUI if VSS support is not required.

Back to Top

Backup Types 

Snapshots, Cloud Snapshot, and Cloud Clones are referred to as backup copies, or backups.  With a legacy data protection policy, it is common to find a waterfall model for protecting data across various technologies, where some overlap exists between each transition in the waterfall.  For instance, local backup copies stored on the primary storage array in the form of snapshots would be retained past the point of the first backup copy written to a virtual tape library (VTL), and multiple VTL copies would be retained past the point of the first backup copy written to physical tape.  Such overlaps are important to ensure sufficient protection should an entire tier of backup copies be lost.

Backup scheduling should be examined in three tiers as shown below, each having the described characteristics:

  • Short-Term Backups – high cost, short retention, high performance for both backup and restore
  • Medium-Term Backups – low cost, medium retention, medium performance for both backup and restore
  • Long-Term Independent Backups – medium cost, large retention, slow performance for both backup and restore, stored independently

Back to Top

Short-Term Backups

As with legacy backup architectures, short-term backups tend to be stored on the most expensive and highest performing media and are retained for the shortest periods of time.  For example, short-term backups in most environments are stored in the form of volume snapshots on the same storage array where the primary volume(s) reside.  Short-term backups are expensive (storage array disk is an expensive storage media) and provide high-performance restores (using fast disk storage and technologies such as copy-on-write or copy-reference-on-write).  While short-term backups are the preferred media from which to perform a restore, cost is generally prohibitive in terms of retaining large numbers of short-term backups for extended periods of time.

In the case of StorSimple, a short-term backup is a snapshot as described above.

Back to Top

Medium-Term Backups

As with legacy backup architectures, medium-term backups tend to be stored on a cheaper tier of storage than the original media used to store the primary copy of data.  For example, medium-term backups in most environments are stored on virtual tape libraries or on-site physical tape libraries.  Medium-term backups are generally less expensive than short-term backups as the media costs less than the media used for the primary copy of data.  Medium-term backups are not considered truly-independent as they are typically retained in the same location as the original media used to store the primary copy of data.  Medium-term backups are used as an intermediary backup copy before off-site, truly-independent copies are created.  This is done to help manage cost while maintaining a reasonable level of backup and restore performance.

In the case of StorSimple, a medium-term backup is a Cloud Snapshot as described above.

Back to Top

Long-Term Independent Backups

As with legacy backup architectures, long-term independent backups tend to be stored on the cheapest tier of storage and off-site in a vault – i.e. a location that is geographically distant, ensuring protection against regional disaster.  For example, long-term independent backups in most environments are stored on physical tape cartridges in a third-party vault hundreds of miles away.  Long-term independent backups may be more expensive than medium-term backups as there are costs associated with not only the media but also the storage of the media in the vault, but almost always less expensive than short-term backups.  Long-term independent backups are kept as long as required based on the retention requirements dictated by corporate policy, regulatory compliance, or other reasons. 

In the case of StorSimple, a long-term independent backup is a Cloud Clone as described above. 

Back to Top

Backup Policies  

 Backup policies for snapshots, Cloud Snapshots, and Cloud Clones are created separately for each volume group (series of related volumes) and dictate:

  • Backup Type – the type of backup to perform (snapshot, Cloud Snapshot, Cloud Clone)
  • Schedule – at what interval and what frequency the backup is executed
  • Retention – how much backup copies to retain
  • State – whether the policy is enabled or disabled

When creating backup policies, it is important to create one policy for each volume group for each type of backup you wish to retain.  As a best practice, it is recommended that three policies be created for each volume group, one for each backup type offered by StorSimple.

Each volume can have up to 256 backup copies, across all policies that reference that volume in the associated volume groups.  It is important to consider this when creating backup policies.  Each policy can have an explicit retention of up to 64 backup copies.  Alternatively, a policy can be set to retain “all” backup copies, but the policy will become disabled once the limit on any volume in the associated volume group is reached.

In order to create the most appropriate backup policies for your volumes, it is important to understand the retention requirements for each type of backup.  This can typically be gleaned by looking at existing retention requirements for legacy backup architectures for each of the various components (i.e. snapshots, virtual tape, physical tape).  It is recommended that the overlap retained between each type of backup be at least as long as the interval used in the policy with the broader schedule.  As an example, when transitioning from a daily snapshot to a weekly Cloud Snapshot, it is recommended that at least two weeks worth of daily snapshots be retained.  Or, when transitioning from a weekly Cloud Snapshot to a monthly Cloud Clone, it is recommended that at least two months worth of Cloud Snapshotshots be retained.

Back to Top

Backup Policy Questions  

The following questions should be answered prior to creating a series of backup policies for a given volume or set of volumes:

  • Volume groups – what volume or volumes do I wish to protect together? 
  • Consistency – do I need application-level consistency or is crash consistency sufficient? 
  • Short-term backup recovery point objective (RPO) – how long do I need to retain local backups for fast restores and at what granularity?
  • Medium-term backup RPO – what granularity is acceptable for my medium-term backups? 
  • Long-term backup retention – how long do I need to retain data and at what granularity?
  • Disaster recovery (DR) – do I need to protect against failures in my medium-term backup repository, i.e. the regional data center for the cloud provider I am using?

Example Policy

The following examples serve to highlight the use of the best practices mentioned above in accordance with answers to the questions listed above.

Scenario 1


The questions mentioned above were answered in the following manner:

  • Volume groups – “I want to protect data for my SharePoint 2010 deployment” 
  • Consistency – “Application-level consistency is required”
  • Short-term backup recovery point objective (RPO) – “I must be able to retrieve data from the last week from a short-term backup copy and not lose more than twelve hours of data”
  • Medium-term backup RPO – “I must not lose more than one week of data when restoring from a medium-term backup”
  • Long-term backup retention – “I must retain my SharePoint data for at least three years.  I prefer to have a monthly off-site long-term backup, rolled up to an annual off-site long-term backup”
  • Disaster recovery (DR) – “Yes, I need protection in case my cloud provider’s regional data center encounters a catastrophic failure”

In this example, three policies would be needed for the associated SharePoint volumes (typically, the database volume, BLOB volume, transaction log volume, and others) as described below, and policies would have to be implemented using the StorSimple Data Protection MMC snap-in for application consistency.

  • Short-term backup
    • A snapshot policy
    • Scheduled to run every twelve hours
    • Retention of two weeks (one week to account for the RPO, one week for the overlap with the medium-term backup policy)
    • Creates a total of 28 backup copies (2 per day for 2 weeks)

 

  • Medium-term backup
    • A Cloud Snapshot policy
    • Scheduled to run every week
    • Retention of ten weeks (five weeks retention plus five weeks of overlap with long-term backup policy)
    • Creates a total of 10 backup copies (1 per week for 10 weeks)

 

  • Long-term backup
    • A Cloud Clone policy (protection against cloud provider failure required)
    • Scheduled to run monthly
    • Retention of thirty-six months
    • Creates a total of 36 backup copies (1 per month for 36 months)

In this example, a total of 74 backup copies are retained.

 

Scenario 2


The questions mentioned above were answered in the following manner:

  • Volume groups – “I want to protect data for my Linux NFS server” 
  • Consistency – “Crash consistency is required”
  • Short-term backup recovery point objective (RPO) – “I must be able to retrieve data from the last week from a short-term backup copy and not lose more than a day of data”
  • Medium-term backup RPO – “I must not lose more than one week of data when restoring from a medium-term backup”
  • Long-term backup retention – “I must retain my file server data for at least one year.  I prefer to have a monthly off-site long-term backup”
  • Disaster recovery (DR) – “No, I do not need protection in case my cloud provider’s regional data center encounters a catastrophic failure”

 

In this example, three policies would be needed for the associated file server volumes.  The appliance web GUI is used for creation of the policies.

  • Short-term backup
    • A snapshot policy
    • Scheduled to run every day
    • Retention of two weeks (one week to account for the RPO, one week for the overlap with the medium-term backup policy)
    • Creates a total of 28 backup copies (2 per day for 2 weeks)

 

  • Medium-term backup
    • A Cloud Snapshot policy
    • Scheduled to run every week
    • Retention of ten weeks (five weeks retention plus five weeks of overlap with long-term backup policy)
    • Creates a total of 10 backup copies (1 per week for 10 weeks)

 

  • Long-term backup
    • A Cloud Snapshot policy (protection against cloud provider failure not required)
    • Scheduled to run monthly
    • Retention of twelve months
    • Creates a total of 12 backup copies (1 per month for 12 months)

In this example, a total of 50 backup copies are retained.

Back to Top

Page statistics
3557 view(s) and 13 edit(s)
Social share
Share this page?

Tags

This page has no classifications.

Comments

You must to post a comment.

Attachments