Advice needed on using Veeam to backup SharePoint Cluster and its SQL DB Cluster?

[pcts]

Taking on support for a new customer that has had a recent SharePoint 2019 install hosted on ESXi.

The guy who originally setup SharePoint setup a full SQL backup to happen each night but the log files had ballooned (esp sharepoint config and main database) as there were no transaction log backups scheduled. He then left.Onsite IT have just put in place Veeam to backup the 6 SharePoint servers (2 x app, 2 x web, 2 SQL) but it looks like there is no application aware backups going on, no truncating of logs files etc. Anyone here using Veeam soley to backup their on premise SharePoint VMS and SQL Cluster and can share how you are backing it up with Veeam?

The SQL servers have Veeam agents installed (I assume since Backup of Cluster Shared Volumes are not supported by Veeam and as the SQL VMs are in a Microsoft failover cluster and utilise bus sharing and share the same SQL DATA,SQL LOG and SQL Backup VMDK files.) Note: There is a separate cluster shared volume for SQL Data, SQL Log, SQL Backup on the SAN.

I am considering at a high level maybe the following might be a good idea but wanted to get your thoughts:
(i) kill the daily SQL full backup plan and move to Veeam full as the complete backup solution for all the SQL Databases (Content, Config, Master etc....)?
(ii) configure daily Veeam incremental backups of App servers, Web Server and SQL OS with maybe full backups monthly and keep clean down incrementals each month.
(iii) weekly Veeam SQL full backup of all SQL Databases, keep for two months?
(iv) daily transaction log backups for SQL DB (or would one do this more frequently), keep for one month?

or would you recommend let SQL Backup and Maintenance plans manage the SQL DB Backups and set Veeam to do everything else?

I assume if Veeam agent is installed on the SQL Veeam can backup the files stored in the SQL Data, SQL Log and SQL Backup CSV as it has direct access to the data in the volumes just can't backup the overall volume itself.

[HannesK]

Hello,
if we back up the SQL cluster today, then they have a normal shared volume (not a cluster shared volumes aka CSVs).

i: I'm not sure what it is about. every incremental backup Veeam does is a logical full
ii: daily incremental sounds good. not sure what you mean with "clean down incrementals". Retention will be applied according to the configuration
iii: you already have that when you configure ii with weekly & monthly restore points
iv: every 480min is the maximum possible for log backups.

I would do everything with Veeam, except you found something that is impossible.

Best regards,
Hannes

PS: I deleted the other post as it was a duplicate.

[pcts]

Thanks HannesK

When you say "except you found something that is impossible." - can you expand on that?

Regards
PCTS

[HannesK]

Hello,
that means if you really have a CSV. I just believe that you have a normal shared volume because it sounds like SQL backup is working fine today with the agent.

If you really have a CSV, then there are other options like
- migrate to shared volume
- use SQL native tools and only back up the dumps

Best regards,
Hannes

PS: sorry if my guess is wrong, but I have seen many customers not knowing the difference between shared volume and CSV

[pcts]

1. Thanks - yes we have a CSV so we can't back up the SQL or CSV via Veeam and will have to use SQL Native tools. Can you describe in this instance if we should use Veeam Agent backup or Veeeam HyperV Backup job? Is there something we get more with Veeam Agent Backup for failover clusters that we do not get with classic backup job. Maybe its that is the quorum is on hard drive utilising bus sharing then the normal job won't back that up?

2. Also in terms of the restore workflow - what would that looklike?
Say we lost the whole VM - would it mean - restore of the VM to hyperv/vmware server, recreation of new VMDK/VHDX files on the server/SAN you are recovering to (setting them up as CSV and adding them to the cluster - removing the references to the old cluster drives) and then recreation of any directory structure within them and then open SQL management studio and recover the database from native SQL backups (taken via maintenance plan).

3. Can you explain what the SharePoint backup option (where you have to put in the farm administrator credentials) is used for in the Agent backup and if one has the SQL DB on CSV - is this SharePoint backup useless as well?

[Dima P.]

Hi pcts,

1. Thanks - yes we have a CSV so we can't back up the SQL or CSV via Veeam and will have to use SQL Native tools. Can you describe in this instance if we should use Veeam Agent backup or Veeeam HyperV Backup job?

Hyper-V backup will always be better that installing agent to a VM.

2. Also in terms of the restore workflow - what would that looklike? Say we lost the whole VM

Restoring both VMs, making sure that the cluster is built (you might need to resync the nodes state if there was a the delay between backups), attaching the csv, using native sql tools to restore data to csv.

3. Can you explain what the SharePoint backup option (where you have to put in the farm administrator credentials) is used for in the Agent backup and if one has the SQL DB on CSV - is this SharePoint backup useless as well?

You still can protect the entire SharePoint site collection (i.e. SharePoint data) but backup of the remote SQL should be performed by another job for sure.

[pcts]

@Dima P. - Thanks for the advice.

1.A Hyper V Backup can't backup a drive that has bus sharing enabled so I think we need to use the agent for the SQL Server (as the quorum hard disk has bus sharing enabled). https://kb.vmware.com/s/article/1006392

1.B. Is there something we get more with Veeam Agent Backup for failover clusters that we do not get with classic backup job. Maybe its that is the quorum is on hard drive utilising bus sharing then the normal job won't back that up?

3.A Sorry I'm lost a bit here. Is there guidance you can provide on what jobs you recommend be put in place to backup this infrastructure? I have 2 x app server, 2 x web servers and 2 x SQL servers (SQL Cluster using CSV and bus sharing). At the moment - we have a separate VMWare backup job which backs up 2 x app and 2 x web servers. Then a separate SQL Agent failover cluster job which backs up the SQL OS and Quorum hard disk (This job has app aware processing enabled and sharepoint tab has been populated with the farm administrator credentials).

3.B I can't seem to find any detailed information on what backup job the "SharePoint" tab in the app aware settings should have the details entered into.

3.B Also since its not a SQL backup - what is the SharePoint tab actually used for and what is it backing up. Isn't the SharePoint data stored in SQL?

[HannesK]

1.A: Hyper-V backup does not work for VMware Anyway: if you have a VM that cannot be snapshotted, then you can only use backup that doesn't require VM snapshots. Agents are the way to go then. Like a physical server.

1.B: if it is a normal shared disk from the operating systems perspective, then the backup will work for a shared disk. What do you on the level below (bus sharing or whatever) is irrelevant from the operating system view.

If you cannot back up everything with Veeam, then Sharepoint backup makes little sense. Veeam needs to have the SQL database in its backups to get the Veeam Explorer for Sharepoint working. The only workaround is moving from CSVs to shared disks (I remember a partner saying that he does that kind of migration regularly. so I assume it it's relatively easy). Well, or migrating to SQL always-on with real VMs and shared nothing architecture

[pcts]

Thanks for the update and answers. So it looks like Veeam does need to have the SQL DB in its backup to allow the SharePoint tab setting to do its thing. I'll have to try and find that partner you speak of to find out how that migration is done.