Resiliant SQL choice

[ejenner]

Hi guys,

We currently have a SQL cluster which Veeam can't backup. So we're dumping the SQL files and backing them up separately.

We're in the very early stages of an SQL upgrade and I want to know what options for a resilient SQL architecture should be on the table if we want Veeam to be able to back it up directly.

Thanks.

[HannesK]

Hello,

We currently have a SQL cluster which Veeam can't backup

can you give us details why Veeam cannot backup that cluster? Is it a Linux SQL cluster? In general, we support almost every cluster configuration for SQL.

Best regards,
Hannes

[ejenner]

I believe since our data resides on shared cluster volumes this is where Veeam gets stuck.

[HannesK]

sorry to be annoying again... what kind of "shared cluster volume"?

Is it a normal "shared volume" or a "cluster shared volume" (CSV)

If you go with a normal "shared volume", then it is supported. CSVs are not supported (which is no problem in most cases because CSVs should be used for Hyper-V. Not for SQL)

As shared volumes are physical devices (no snapshot, no storage VMotion), you need to treat them as physical devices (Veeam Agent for Windows). Or you switch to shared nothing architecture with SQL Always ON availability groups. Then you could VM backup

[ejenner]

Our SQL data is on a CSV. Hence can't back it up.

I didn't design our original solution so not sure if CSV is a good or bad idea... but that's what currently blocks us from backing up our SQL directly.

So the original question still stands. When we design our new solution knowing we will want to be able to protect it with Veeam, from the Veeam perspective, what is the best for backing up?

[HannesK]

there is no "best". always on (shared nothing) and shared volume (agent only) are fine.

just don't use CSV

[MariusN]

Our SQL data is on a CSV. Hence can't back it up.

I didn't design our original solution so not sure if CSV is a good or bad idea... but that's what currently blocks us from backing up our SQL directly.

So the original question still stands. When we design our new solution knowing we will want to be able to protect it with Veeam, from the Veeam perspective, what is the best for backing up?

as posted before if you want to run a cluster i would recommend Always ON Availability groups with shared nothing disks -> protection by veeam possible
if its a standalone sql server you can backup it normally by Veeam.

[ejenner]

Well I know from what we've purchased so far that we'll certainly have two 'nodes' for our SQL solution. The storage will be on a SAN. Pretty similar to our current setup.

We may be going off track here... but interested to hear 'why' CSVs shouldn't have been used for our existing SQL cluster. It's not something I know much about but obviously if it looked like we were going to make the same mistake when building the new cluster I'd like to know why it shouldn't be done that way.

[nmdange]

Just to be clear, are you talking about a physical SQL cluster or virtual (and if virtual, Hyper-V or VMWare)?

[HannesK]

'why' CSVs shouldn't have been used for our existing SQL cluster.

I don't have a "why not". I just remember https://docs.microsoft.com/en-us/window ... uster-csvs and it looks to me that CSVs are built for Hyper-V. Yes, they are also supported for SQL 2012 and newer... but this causes issues with for the Veeam agent as it currently does not support CSVs.

[ejenner]

The fact that they're not supported by Veeam is enough reason not to use them again. It would've boosted my case though... if I had 2 reasons.

[Nerdz]

Throwing my 2 cents in here. We have a few SQL/Oracle Windows clusters and how we do it is we only backup the C:/E: (code) drives with Veeam. Database/log drives on cluster drives are not backed up. We also do not have any DB backup drives on the local server. All of our SQL boxes backup to either a CIFS server or are now are moving to a Data Domain. The database/log drives will be a hot mess if you try to restore them anyway so we don't bother to back them up. Our backups on 40+ complete in under 30 minutes total due to how we are backup up.