Forum Discussion
How we can be sure that we have sufficient backups for our sharepoint on-premises 2013/2016
We have sharepoint on-premises servers 2013/2016 , which have the following architecture:-
1. windows server 2012/2008 R2 which act as the application servers.
2. windows server 2012/2008 R2 which act as the database servers.
now our IT admins, take snapshots of the servers (application + database) on daily basis + to have additional restore point (in case we faced a sever damage to our servers) i run this command on daily basis to have a backup for the whole farm :-
Backup-SPFarm -Directory \\*****\backups\ -BackupMethod full -BackupThreads 10 -Force
but my questions, if our approach is sufficient to covers these scenarios:-
1. let say the database server had a major hardware/OS problem, and we are not able to have it working again. then will the snapshot we have for the database be able to recover us from the database server failure?
2. similar to point one, but let say the application server had a major hardware/OS problem? will the snapshot be sufficient to recover us from the application server failure?
3. since our IT admin are taking snap shots of the servers, then is there any need to do a Backup-SPFarm? as this command will created a huge backup files.
Thanks in advance for any help.
Hi John,
I always ensure SQL backups of both the Configuration Databases and Content Databases are made. This is the best / fastest / most reliable way to get back online in a real disaster. You can use transaction log backups to have more recovery points e.g. restore full backup + incremental (transaction log) up to the recovery point. I am talking about SQL Database Backups using a SQL Maintenance plan.
It is also a good idea to have snapshots of the SharePoint Servers themselves - this includes all of the file system bits you will need to recover.
Content Database backups also allow you to recovery sites, libraries, lists and documents using the 'Unattached' restore process via Central Admin.
The Farm Backup is may be useful in a disaster and can be scripted / scheduled.
I blogged about this a while back too. This might be helpful https://onehundredwatt.wordpress.com/2016/10/30/recovering-sharepoint/
SteveKnutsonthanks a lot for your valuable reply. please find my comments:-
I always ensure SQL backups of both the Configuration Databases and Content Databases are made. This is the best / fastest / most reliable way to get back online in a real disaster. You can use transaction log backups to have more recovery points e.g. restore full backup + incremental (transaction log) up to the recovery point. I am talking about SQL Database Backups using a SQL Maintenance plan.yes we always backup the sharepoint databases from the server itself, we do this on daily basis after business hours. so the maximum loose for the data will be 24-- hours, which is according to our SLA agreements with the customers. we back up all the current sharepoint databases which got created for us when we install sharepoint + any new database which got created a part of provisioning new managed service (such as managed metadata, etc..). so we already covering this point.
It is also a good idea to have snapshots of the SharePoint Servers themselves - this includes all of the file system bits you will need to recover.now we are already taking snapshots of the sharepoint application server, on daily basis also. although on this link it mentioned that it is not a recommended way https://blogs.msdn.microsoft.com/sambetts/2015/08/24/virtual-machine-snapshots-for-sharepoint/ . although if we face a real disaster problem, then having a snapshot of our sharepoint application server will be very beneficial to us.
Content Database backups also allow you to recovery sites, libraries, lists and documents using the 'Unattached' restore process via Central Admin.
but the database backup in general and the content database backup specifically, will not be beneficial to us if the sharepoint application server got sever damage?is this correct? in this case to benefit from the database backups we will need to create a new sharepoint application server which have the exact patch level as the old/damaged server. so i am not sure how we can do so (backup the sharepoint patches info)? as in our case some of our servers are been patched each 3-6 months , where this patch process install security updates for windows and sharepoint, and after that we run the sharepoint product configuration wizard.. so how i can backup the sharepoint server patches in a way that can allow us to apply similar patches to a new server incase the old VM got sever damage?
The Farm Backup is may be useful in a disaster and can be scripted / scheduled.
restoring farm backup will need a farm with the same patch level. also let say the sharepoint application server got sever damage, then we can not do a Reestore-SPFarm ?? or we can still do so?
can you please advice on my points? and thanks for your helpful reply.
Configuration database/admin database restores are not a supported scenario. Nor are snapshots/online backups of VMs (this is just like Exchange which doesn't support this functionality nor is it recommended with SQL Server). Instead, consider creating a standby farm in your DR location. This will provide you with the highest availability in a DR event.
The Config/Admin databases would be created when you rebuilt the farm. The `Backup-SPFarm -ConfigurationOnly` would allow you to restore, after building the farm, elements contained within the Configuration database.
> will not be beneficial to us if the sharepoint application server got sever damage
App Servers do not store data (sans Search Index which is easily rebuilt). It is the databases you need. Any SharePoint server, be it FE or BE can just be rebuilt from scratch fairly easily. This is the preferred approach. Creating a sysprep'ed VM with SharePoint + appropriate patches will get you online with that specific role the fastest.
I'd suggest you review the following and get back to us with any questions.
https://docs.microsoft.com/en-us/sharepoint/administration/backup-and-recovery-overview
https://docs.microsoft.com/en-us/sharepoint/administration/high-availability-and-disaster-recovery-concepts
- Configuration/Administration databases cannot be restored. If a farm wasn't built with PowerShell, then using `Backup-SPFarm -ConfigurationOnly` is appropriate. Other than that, use SQL jobs to backup databases.
Trevor Seward wrote:
Configuration/Administration databases cannot be restored. If a farm wasn't built with PowerShell, then using `Backup-SPFarm -ConfigurationOnly` is appropriate. Other than that, use SQL jobs to backup databases.Trevor Sewardcan you advice what do you mean by configuration/administration databases cannot be restored? are those usual sql databases that can be backed-up from sql management studio and got restored?? and how we can recreate these databases if we faced an issue that require restoring the Configuration/Administration databases ?
