Taking regular backups of SharePoint is an important aspect of SharePoint Administration as the granular recovery of the SharePoint items is a core part of an administrator’s job. The backup and recovery challenges which accompany the growing volume of SharePoint data demand that the administrators externalize the BLOB data.
The separation of content database from BLOBs means you have distinct, independent elements which are needed to be backed up. Content database resides in SQL Server. BLOB index, which the StorageEdge maintains for the externalized blobs, exists either separately or within the content database. Similarly, the externalized BLOBS may be sitting on files, NAS, SAN or Cloud. So, you need to give serious consideration to the order in which you plan your backup of these distinct elements.
SharePoint performs two distinct operations on the BLOB items – Add and Delete. The Update is handled by SharePoint as an Add operation as it doesn’t overwrite the existing BLOBs. Let us analyze some of the scenarios, which you need to be aware of, which potentially might evolve during the course of backup vis-à-vis these operations and the order of the backup and impact on restore.
Consider a situation when new content is added and the externalized content is backed up first and the content database subsequently. In this scenario, StorageEdge will update the content database and the BLOB index with new entries but backup will not have the content in it. If this backup is restored, an inconsistency will occur since the content database and BLOB index will contain content entries that will not be present on the external storage. This will give rise to a dangling reference and generate a “file not found” type of errors when the item is requested within SharePoint.
Similarly, if an item is deleted from SharePoint when the BLOBs are being backed up first and the backup is in progress, the item might have already been backed up. On delete, the entry will be removed from the content database, the BLOB index of StorageEdge and from the physical storage as well. However, if this backup is restored at some point in time, the deleted BLOB will be restored but it will not have a corresponding entry in the BLOB index of StorageEdge as well as the content database. Such deleted content will also not show up in SharePoint. However, it will reside as an Orphan BLOB on the external storage. Such repeated backups and restores may produce a large number of orphan blobs occupying storage unnecessarily.
So, whenever you backup the content externalized using StorageEdge, it is important that you backup the content database and the BLOB index first before the BLOB store to avoid data inconsistencies. Similarly, the restore must take place in the reverse order. This is essential to avoid potential inconsistencies.
Figure 1: Right Order of Backup with Externalization Using StorageEdge
The garbage cleaner of StorageEdge helps you tackle the issues of dangling references and the orphan BLOBs. But you still need to be mindful of the fact that when you externalize your BLOBs, the order in which you backup/restore various SharePoint elements is crucial. Otherwise you might end up with dangling references and orphan BLOBS.