How we can be sure that we have sufficient backups for our sharepoint on-premises 2013/2016

[john john]

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.

[#2]

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/ 

[#3]

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.

[#4]

I've restored Config and Administration databases to recover a farm when a CU failed successfully on two different farms. Process was to restore the databases and then reapply the CU and run PSConfig. 

[#5]

@Steve Knutsonthanks 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.

[#6]

---

@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 ?

[#7]

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-c...

[#8]

---

@Trevor Seward wrote:
Instead, consider creating a standby farm in your DR location. This will provide you with the highest availability in a DR event.

---

but we can not implement this scenario for all our customers, as you know creating standby farm means more cost, which can not be a prerequisites to have a sharepoint. again we are not looking for high availability, but we are looking for an acceptable scenario to be able to restore our sharepoint farm (after a disaster recovery) with maximum of 24 hours data lose.

---

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 know that sharepoint application servers do not store any data... but at the end if we are backup-ing our databases, or the problem we faced is within the sharepoint application server itself, then how we can benefit from the sql backups? as we will need to create a sharepoint application server which have the exact same patch level as the original server... or this is NOT a must? For example is this scenario considered valid:-

let say our sharepoint application server got sever damage and we were not able to turn it on.  but we have our database server working. then can we build a sharepoint application server from scratch >> link it to the available databases >> then install the latest full CUs for sharepoint (or a full CU which is higher than the latest individual sharepoint update we had on the damaged server) >> run the product configuration wizard? will this allow us to work with the sharepoint farm again? of course we have to fix any issues that might result in having our farm been upgraded to different patch level?? what do you think?

thanks for your replies.

[#9]

24 hours of data loss is very high. A simple scenario of using SQL backups on a more frequent basis would solve that. Or do you mean time to recover (RTO) is 24 hours? To get a three node farm online (FE + BE + SQL) can be done in a matter of just a few hours, especially if you already have a VM template ready to go. Heck, I've built a full highly available farm by hand, including AOAG SQL, in under 4 hours :)

> or the problem we faced is within the sharepoint application server itself, then how we can benefit from the sql backups

You shouldn't be focused on an individual SharePoint server. They're disposable. Again, have a VM ready to go that you can quickly deploy as a replacement server. And make sure you have highly available farms (2 FEs, 2 BEs, AOAG SQL). Yes, you need to have the server patched to the same or greater level which means you must keep the templated VM up to date to a certain extent.

> then can we build a sharepoint application server from scratch >> link it to the available databases >> then install the latest CUs for sharepoint (or a CU which is higher than the latest CU we had) >> run the product configuration wizard?

Not quite. You build your SharePoint server, patch it appropriately, then run the Config Wizard to join it to the existing farm.

Again, having multiple SharePoint servers per role will keep you out of this scenario except in cases where the entire data center is a total loss. The only solution to that is a remote standby farm or a fully scripted farm build and obviously Content/Service App database backups.