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

Resiliant SQL choice

Post by ejenner » Jan 08, 2020 10:09 am

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
Veeam Software
Posts: 5126
Liked: 681 times
Joined: Sep 01, 2014 11:46 am
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by HannesK » Jan 08, 2020 12:40 pm

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
Expert
Posts: 485
Liked: 79 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by ejenner » Jan 08, 2020 2:19 pm

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

HannesK
Veeam Software
Posts: 5126
Liked: 681 times
Joined: Sep 01, 2014 11:46 am
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by HannesK » Jan 08, 2020 2:27 pm

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
Expert
Posts: 485
Liked: 79 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by ejenner » 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?

HannesK
Veeam Software
Posts: 5126
Liked: 681 times
Joined: Sep 01, 2014 11:46 am
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by HannesK » Jan 08, 2020 3:28 pm

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

just don't use CSV :-)

MariusN
Influencer
Posts: 10
Liked: 1 time
Joined: Jun 12, 2017 11:21 am
Full Name: Marius Neumann
Contact:

Re: Resiliant SQL choice

Post by MariusN » Jan 08, 2020 3:29 pm 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
Expert
Posts: 485
Liked: 79 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by ejenner » Jan 08, 2020 4:16 pm

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
Expert
Posts: 489
Liked: 124 times
Joined: Aug 20, 2015 9:30 pm
Contact:

Re: Resiliant SQL choice

Post by nmdange » Jan 08, 2020 4:43 pm

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

HannesK
Veeam Software
Posts: 5126
Liked: 681 times
Joined: Sep 01, 2014 11:46 am
Location: Austria
Contact:

Re: Resiliant SQL choice

Post by HannesK » Jan 09, 2020 8:42 am

'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
Expert
Posts: 485
Liked: 79 times
Joined: Mar 23, 2018 4:43 pm
Full Name: EJ
Location: London
Contact:

Re: Resiliant SQL choice

Post by ejenner » Jan 09, 2020 9:15 am

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 » Jan 13, 2020 1:21 pm

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: Majestic-12 [Bot], stewart.hamblin and 44 guests