Simple Backup ServiceLet's face it, you never know when the need will arise to restore or recover your data. We’ve all “been there, done that”, or we have it in the back of our mind that we’ll need to do it someday. However, the odds are that the need to restore won’t be triggered because of a disaster or a hack, but more likely because of common reasons such as: system/user error, corrupt data, deleted data, new environments, a legal hold request, or a Governance, Risk Management, or Compliance (GRC) program which requires that the data must be restored as proof that the data is being retained.

Whatever the case may be, the key to understanding data restoration is knowing that data backups are taking place to begin with; which means planning, implementation, and execution. These tasks can be daunting and riddled with details, which is why they are typically assigned to an operations team (including the planning). However, there are other contributors to backup planning: business owners, product owners, application/database owners, etc., especially when they have a vested interest in restoring or recovering after an issue or event has occurred. Naturally, you want (and need) the correct data restored as soon as possible.

As with any planning process, examining the considerations and asking the right questions to explore is important. This is also true regarding any plans for implementing and utilizing backups as well. To help with this planning step, and make it a little less overwhelming, we’ve outlined a few of the most common aspects and elements to explore when planning your backups. These considerations apply to developing a backup strategy for any compute environment, whether it's on our Cloud Platform or on-premises enterprise IT infrastructure. Or, even your own home network!

  1. Deciding what data to actually backup. The growing list of applications and data is endless, but focus on the main ingredients that are required to restore. Start with these factors:

    • Data: Files, logs, configuration data, etc.
    • Applications or databases
    • Servers: Determine what servers have the data or applications that are critical, and which ones are not as critical (i.e. Dev/Test).
    • Data that contains personally identifiable information, or falls under HIPPA, PCI, legal, governance, risk management, or compliance.
  2. Frequency of backups. How often to backup? The frequency of backups will vary depending on the specific industry and business need. Here are a few things to consider when deciding the frequency:

    • A pre-determined frequency: once a day, once a week, once a month or once a year.
    • Throughout the day (e.g. four times a day).
  3. Determine how long to retain the backups. What is the retention period: days, weeks, months, years? This, too, will vary depending on industry, business, and GRC. Keep in mind that the end of the retention period triggers the backup(s) to be deleted. Here are common retention periods:

    • 1 day, multiple days (such as 8 days)
    • 1 week, 2 weeks, 1 month, 3 months, 6 months
    • 1 year, 2 year, 3 year, 5 year, 7 year, 10 year
    • Another retention pattern is on a rotation. For example, on the 8th backup, discard the first/oldest backup. And, for each backup going forward, delete the oldest backup in the series.
  4. Where to store the backups? In some environments, there is no choice but to store the backups at the site that the backups occur. However, whether it's by choice or requirement, consider these options.

    • At the same facility. Advantage: Increases the speed of the backups and restores. Disadvantage, if the site goes down, the backups go down too.
    • At a separate facility, also known as “offsite storage.” Advantage: copies of the backups are available if the primary site goes down. Disadvantage: speed of backups and restores is negatively impacted.
    • Another option is to store the backups at multiple locations. This is addressed below.
  5. Do the backups need to be replicated/copied to another storage location? This is also sometimes called "offsite storage." This, too, is often needed because of a compliance requirement.

    • This helps protect against original backups that are not available or not usable for whatever reason.
    • Decide if the following are in scope of your requirements:
      • How many replications/copies are needed? Typically, one copy is needed, but sometimes two copies are needed.
      • What location will they be replicate/copy to?
      • How often will they be replicate/copy? Is it the same frequency as the backups. See #2 above regarding frequency.
      • Storage of replicated backups often aligns with #4 above regarding storing the backups.
  6. Testing: Prior to an issue occurring, plan and execute a test restore for the following reasons:

    • Validate that business operations can resume because the data is restored and operational.
    • Verify that an environment can be re-created for dev/test or production.
    • Confirm that you are compliant with legal and/or GRC requirements.


By taking the items above into consideration, you can outline the key ingredients needed for planning your backups. You can also avoid backing up everything because of not being sure what to backup, which leads to unnecessary resource burden and costs. Good planning helps with the process of configuring the backups and execution of backups. All of which puts you in a good position to restore if there is an issue such as an accidental user deletion or an outage.

Stay tuned for future posts to which other backup topics will be addressed, such as Cloud Backups!