Comprehensive data protection for all workloads
Post Reply
ejenner
Veteran
Posts: 636
Liked: 100 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Resiliant SQL choice

Post by 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
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by 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
Veteran
Posts: 636
Liked: 100 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by ejenner »

I believe since our data resides on shared cluster volumes this is where Veeam gets stuck.
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by 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
Veteran
Posts: 636
Liked: 100 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by 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
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by HannesK »

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

just don't use CSV :-)
MariusN
Influencer
Posts: 15
Liked: 1 time
Joined: Jun 12, 2017 11:21 am
Full Name: Marius Neumann
Contact:

Re: Resiliant SQL choice

Post by MariusN » 1 person likes this post

ejenner wrote: Jan 08, 2020 3:22 pm 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
Veteran
Posts: 636
Liked: 100 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by 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
Veteran
Posts: 527
Liked: 142 times
Joined: Aug 20, 2015 9:30 pm
Contact:

Re: Resiliant SQL choice

Post by nmdange »

Just to be clear, are you talking about a physical SQL cluster or virtual (and if virtual, Hyper-V or VMWare)?
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by 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
Veteran
Posts: 636
Liked: 100 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by 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
Novice
Posts: 5
Liked: 1 time
Joined: Nov 14, 2019 1:15 pm
Contact:

Re: Resiliant SQL choice

Post by 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.
Post Reply

Who is online

Users browsing this forum: Amazon [Bot], Google [Bot] and 140 guests