In the last few weeks, I have had many discussions with our customers in the Benelux region regarding backup for SharePoint deployments. One customer pointed out to me clearly why they conduct backups, only in order to restore content and customizations in case they are needed. That’s taking into account, however, that the organization decides that it actually cares about being able to restore content if it is accidentally lost or deleted. If there is no need to restore content, then why even bother to backup SharePoint environments? In short, restoring lost data should not be the only concern – there are more needs for a data protection solution.
Let’s look at backup and restore through the prism of Information Technology Infrastructure Library (ITIL):
· IT Service Continuity Management: This is the process that will support Business Continuity Management, in case of a disaster – such as your data center burning to the ground. In short, an insurance policy for your technology infrastructure.
· Availability Management: This is the process that will make sure that data is available. This is where restores of certain elements come in to play – in terms of SharePoint, this can be a document version, list, site, etc.
If you take the aforementioned processes into account, then it is vital that not only the data – but also the customizations and other SharePoint elements should be incorporated into a comprehensive data protection strategy. More than just SQL Server content databases, it should include the web front end servers and all other SharePoint environment elements. Again, platform restoration – particularly out-of-place restore – is important in terms of disaster recovery. This is an insurance policy, and I sincerely hope it is one you never have to actually utilize.
Something that we will utilize more frequently, though, is restoration of sites or documents. Particularly on-the-fly – as accidents can occur when users mistakenly delete documents or other data they need to perform their daily business tasks. There are two additional terms for this case that are important to review:
· Restore Time Objective (RTO): The duration of time within which a business process must be restored after a disaster or data loss in order to avoid unacceptable consequences associated with a disruption in business continuity. This maximum acceptable downtime of a site, system, network, or application during a failure or disaster, usually based on lost revenue or productivity measured in seconds, minutes, hours, or days and corresponds to the measurable uptime (e.g. 99.99%) within a Service Level Agreement
· Restore Point Objective (RPO): It is the maximum tolerable period in which data might be lost from an IT service due to a major incident.
There is a great deal of emphasis on the RTO, so you’ll find many vendors’ features focus on how you can easily restore a single item. And of course this is important – if you’d like to find out more about how AvePoint’s DocAve Backup and Restore addresses this with InstaMount™ technology, please visit our website. What I see as becoming increasingly important, however, is the growth of SharePoint usage in the process management arena. Organizations are using SharePoint for increasingly business-critical processes. Let’s take expense reporting as an example: Expense reports always need signatures and approvals, so building a workflow to take these pieces into account are important. Particularly at the end of fiscal periods, there will be an influx of expense reports for approval – which can perpetuate many changes to document workflow. This can have an immediate impact on the acceptable RPO.
If your RPO is 24 hours, that is not acceptable for the expense site, because that might result in the effect that a manager needs to redo say 20 approvals, and 20 people need to recreate a document. That is a major loss of productivity and money. This data should be backed up more frequently, because in the case of a restore, we would not want to go back more than an hour, or even 15 minutes, depending on business requirements.
So while I do agree with the customer that restores, while important, should be easy – a granular backup is just as important as a granular restore. This should be taken into account when creating data protection regimes for your SharePoint environment.
