Table of Contents<\/p>\n\t\t\t\t
- <\/ul>\n\t\t\t\t<\/div>\n
- Other documentation relating to procedures and workflows<\/li>\n
- Disaster recovery plans within the organization<\/li>\n<\/ul>\n
This index section can be periodically updated as companies\u2019 libraries of internal backup documentation continue to expand and evolve.<\/p>\n
Further reading<\/span> Guide to MSP Internal Documentation: Principles and Practices<\/a><\/p>\n
Responsibility<\/h3>\n
To maximize the effectiveness of disaster recovery (DR) efforts, the backup policy should also clearly outline areas of responsibility for an organization\u2019s approach to backup. For instance, the document should lay out which team member is responsible for backing up and restoring which systems. Many organizations choose to specify a job function (title) rather than an individual in case people leave the company.<\/p>\n
When You Need A Formal Backup Policy<\/h2>\n
Certain companies are likely to be able to manage just fine without a formal backup policy. However, there are circumstances in which authoring this kind of document is essential.<\/p>\n
Such companies include:<\/p>\n
- \n
- Companies that need to manage sensitive data that falls under standards or legislation. For instance, healthcare companies need to manage patient data, like electronic medical records (EMRs) in accordance with the standards set down in the HIPAA legislation<\/a>. Companies in this space may be subject to governmental audits. In many instances, they are also obliged to have a formal policy backup in place documenting how backup data is managed. In other instances achieving compliance with a data governance standard may require that a backup policy be documented and maintained.<\/li>\n
- Besides healthcare, this requirement may affect companies operating in the financial services and legal spheres, among others.<\/li>\n
- Large organizations might also require backup policies because these companies are more likely to appoint a dedicated person, or team, for managing backup. Backing up multiple systems typically involves more complexity. A formal backup policy is very useful in these cases to set down standards for the workflows of many delegated backup administrators.<\/li>\n<\/ul>\n
Further reading<\/span> Guide to Backup Management for MSPs<\/a><\/p>\n
\n\nEssential Guide to Backup for MSPs<\/div>\nBackup best practices and tips on how to protect your customers\u2019 sensitive data<\/div>\n![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/d7a3df42-5072-4766-aac8-e2bc23caa204.png\")
<\/a><\/span><\/span>\n<\/div>\n![\"WP](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2019\/12\/Backup-best-practices-icon-2.png\")
<\/div>\n<\/div>\nOther Backup Policies<\/h2>\n
In addition to a formal backup policy, other backup documentation can sometimes be called \u201cbackup policy\u201d. If you are tasked with creating a \u201cbackup policy\u201d, but you clearly understand that it\u2019s not a formal document, you should better ask about the exact nature of the needed document. Here are some popular examples:
\nDisaster Recovery Plan
\nThe disaster recovery (DR) plan typically consists of detailed documentation outlining exactly what steps the business will have to take in order to restore from any of a number of disasters. The DR plan will typically set out detailed instructions for restoring key mission-critical business functionalities and also stipulate a personal responsibility for executing each task in the plan.<\/p>\nDR plans are vital and often the first pieces of documentation that those involved in continuity go looking for when something goes wrong. But they don\u2019t set down the same overarching standards as a backup policy typically does.
![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/a99bf554-4786-40d2-8e73-43bf625d6417.png\")
<\/a><\/span><\/span><\/p>\nFurther reading<\/span> Building a Cloud Disaster Recovery Plan: Tips and Approaches<\/a><\/p>\n
Backup Retention Policy<\/h3>\n
The backup retention policy specifies the time periods for which backups need to be retained in the organization. This particular policy can be informed by the regulatory policies that the company has to comply with.<\/p>\n
Further reading<\/span> Backup Retention Policy and Scheduling Best Practices<\/a><\/p>\n
RTO \/ RPO Considerations<\/h3>\n
The recovery time objective<\/a> (RTO) and recovery point objective<\/a> (RPO) specify the maximum amount of time that can elapse from a declaration of a disaster through to the restoration of services and the maximum amount of data that can be lost in the restore process respectively. Sometimes companies will create a separate backup policy document setting out the RPO and RTO targets for every business system with mission-critical tools (like CRMs and ERPs) typically having more ambitious objectives than less essential IT services<\/p>\n
Further reading<\/span> Recovery Time (RTO) and Recovery Point (RPO) in DR Strategy<\/a><\/p>\n
Backup and Recovery Frameworks<\/h2>\n
Finally, any document(s) that have to do with the overall backup and disaster recovery<\/a> process might tend to be referred to as \u201cpolicies\u201d \u2014 even if they merely contain information or were intended as reference documents. Examples of this kind of document might be:<\/p>\n
- \n
- An inventory of all current systems<\/li>\n
- A contact directory of all staff responsible for backup or an organizational chart of the backup decision-makers<\/li>\n<\/ul>\n
Best Practices For Creating A Backup Policy<\/h2>\n
All backup policies are not created equal and some IT teams do a better job of creating them than others. If you\u2019re been charged with preparing one for your department or workgroup then you should draft it with the following best practices in mind.<\/p>\n
- \n
- Understand the purpose:<\/strong> Remember that the backup policy is intended to set down the overall direction for how your organization is to run backups and DR. Take an inventory of existing backup \u201cpolicies\u201d including the ones we referred to in the previous section. Draft a document that sets down guidelines that these policies meet. After all, the document you\u2019re about to create should be the central source of knowledge that will inform the creation of future derivative documents.<\/li>\n
- Fill the gaps:<\/strong> If, on the other hand, your organization doesn\u2019t have any backup documentation, then see this as your chance to begin creating it. You might wish to begin thinking about what credible target RTOs \/ RPOs might look like for the various systems and data repositories you\u2019ll want to be backing up.<\/li>\n
- Clear language: <\/strong>Backup policies don\u2019t tend to make good bedside reading. Bear in mind that people are likely going to be skimming your document in order to access the required information. Therefore adhere to a clear structure. Use headings and subheadings to highlight information logically. Use easy to understand language.<\/li>\n
- Reviewed by legal department or lawyer:<\/strong> Because backup policies often touch up on data governance, they may raise compliance issues \u2014 particularly for organizations that are bound by certain statutes. If this is the case, then make sure that your policy has received all the appropriate internal sign-offs, including from your law officer or legal department.
\nFurther reading<\/span> The Importance of Legal Services to MSPs Explained<\/a><\/li>\n- Tested:<\/strong> All backups should go through test restore processes. The policy should be a living document that reflects actual backup workflows. If a policy isn\u2019t feasible \u2014 or it can\u2019t be tested \u2014 then it shouldn\u2019t be documented.
\nFurther reading<\/span> How to Test Your Backups: A Comprehensive Guide<\/a><\/li>\n- Regularly updated:<\/strong> Don\u2019t forget to include a field for periodic updates so that the document can be kept updated and readers can see when it was last revised. It\u2019s especially important to include this field if your corporate governance dictates that all policy documents need to be revised and updated at fixed intervals.<\/li>\n<\/ul>\n
A Strong Policy Governs Good Backups<\/h2>\n
Managing backup and DR in the enterprise environment is a complex process and the person entrusted to lead it is responsible for maintaining the integrity of data across multiple business systems.<\/p>\n
To ensure continuity and operational efficiency, a central backup policy should be documented and periodically revised. This is the central document that can serve to set down agreed best practices and RTO\/RPO for all staff members involved in the backup.<\/p>\n
Those drafting the document should remember that the document should be considered the first source of backup knowledge in the company. It should supersede and agree with other existing \u201cbackup policies\u201d in the company, which may in fact simply be frameworks. The document should have a nominated custodian and be periodically updated with a clear revision date update (and sometimes a changelog) after every edit.<\/p>\n","protected":false},"excerpt":{"rendered":"
If you\u2019re responsible for managing backups in an organization, then you might have been asked to author a backup policy (but been unsure about what exactly it entails). A backup policy is a formal document setting out the high-level governance of backups within an organization.<\/p>\n","protected":false},"author":59,"featured_media":49118,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[883,877],"tags":[],"class_list":["post-49114","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-backup-and-dr-articles","category-blog-articles"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/49114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/users\/59"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/comments?post=49114"}],"version-history":[{"count":6,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/49114\/revisions"}],"predecessor-version":[{"id":58128,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/49114\/revisions\/58128"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media\/49118"}],"wp:attachment":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media?parent=49114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/categories?post=49114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/tags?post=49114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Fill the gaps:<\/strong> If, on the other hand, your organization doesn\u2019t have any backup documentation, then see this as your chance to begin creating it. You might wish to begin thinking about what credible target RTOs \/ RPOs might look like for the various systems and data repositories you\u2019ll want to be backing up.<\/li>\n
- Understand the purpose:<\/strong> Remember that the backup policy is intended to set down the overall direction for how your organization is to run backups and DR. Take an inventory of existing backup \u201cpolicies\u201d including the ones we referred to in the previous section. Draft a document that sets down guidelines that these policies meet. After all, the document you\u2019re about to create should be the central source of knowledge that will inform the creation of future derivative documents.<\/li>\n
- Companies that need to manage sensitive data that falls under standards or legislation. For instance, healthcare companies need to manage patient data, like electronic medical records (EMRs) in accordance with the standards set down in the HIPAA legislation<\/a>. Companies in this space may be subject to governmental audits. In many instances, they are also obliged to have a formal policy backup in place documenting how backup data is managed. In other instances achieving compliance with a data governance standard may require that a backup policy be documented and maintained.<\/li>\n
What Is A Backup Policy?<\/h2>\n
A backup policy<\/strong> is a formal document that sets down guidelines for how backups should be handled within a company. The document could set down procedures, responsible parties, and specify related documentation (we\u2019ll review the contents of the typical backup policy later in the article).<\/p>\n A formal backup policy differs from other documents in the organization which might describe themselves as backup policies. These could, for instance, be the backup or disaster recovery (DR) plans<\/a> which certain parts of the business \u2014 like the marketing or sales teams \u2014 have prepared.<\/p>\n While these policies might pertain to specific technical systems, only the formal backup policy is the overarching document that is responsible for setting company-wide backup direction. Backup policies have strict structures and may require input from HR and legal teams, among other stakeholders.<\/p>\n Further reading<\/span> Creating Resilient Backup Policies: A Step-by-Step Guide<\/a><\/p>\n As an official corporate document, the backup policy will tend to follow a tried and tested formula. Some of the fields that should be included are:<\/p>\n The statement component of the backup policy will state the key information about the backup policy such as the document\u2019s formal title, how it should be referred to internally, what date it was prepared on, and who was responsible for authoring it.<\/p>\n The purpose section will typically state what the backup policy is meant to achieve. It might say, for instance, that the policy is intended to standardize backup procedures across the organization.<\/p>\n If your organization is large enough to be authoring a backup policy, then the backup policy should also probably clearly delineate its scope. The backup policy might spell out exactly which employees (or departments) and assets fall under the governance of this backup policy. It\u2019s always better to be clear than ambiguous. So if there\u2019s any room for doubt about whether the backup policy will apply to a certain team, it\u2019s better to state it in the document.<\/p>\n If your IT team has a formal Backup Manager, then he or she may be charged with periodically reviewing and updating all the existing backup documentation in an organization. For that reason, it\u2019s worth including a list of all the other backup-related documents within the company. If the backup policy is going to be a digital file (or hosted in a knowledge management system like Confluence) then you could either embed the other documents or link off to them here.<\/p>\n The related documentation, specifically, could map out:<\/p>\nFormal Backup Policy<\/h2>\n
Statement<\/h3>\n
Purpose<\/h3>\n
Scope<\/h3>\n
Related Documentation<\/h3>\n
![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/aa07fdb8-7776-46a5-9fa0-ec6e93f0f0a6.png\")
<\/a><\/span><\/span><\/div>\n\n