Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

SQL Server Database Backup Strategy for Low Downtime Environment - How To?

I am curious what other folks are doing for DR and HA for their Orion SQL Databases?

Today after working with SolarWinds technical support on an Orion performance issue I was informed that Full Recovery Mode on the Orion SQL Server is NOT supported.

We currently were running in Full Recovery Mode to support Transaction Log Shipping to a standby SQL Server.

I was told by the SolarWinds SQL guy that I spoke with that they only supported Simple Recover Mode and suggested that I just do SQL Backups.

After doing a bit of research on the SQL Server Backup methods, everything I read said that when dealing with transaction type data in a low downtime environment that you should be using Full Recovery Mode.

This brings me to my question, what are other people doing to backup their Orion SQL Server in a low downtime environment so that their data is protected?

Find more posts tagged with

Accepted answers

All comments

byrona

Bump

Really need some direction on this one, thanks!

MarieB

Hey Byron--

I'll research this and get back to you.

MarieB

Hi byron--

Did some checking and want to clarify a couple of items for both your benefit and that of the community.

As I understand it, SW doesn't tout Orion NPM as a true low downtime application. I know it may act like it sometimes, but in the strictest sense, it is not.

We don't support Full Recovery Mode b/c the performance hit to do so outweighs the benefit of Full Recovery. We opt instead to use Simple Recovery Mode.

Not a very satisfying answer to be sure.

I will mark this for PM and if you want to private message Brandon off-line to discuss, I'm sure he will listen.

m_roberts

The advice given is correct for larger installations, which is usually where the DR failover requirement exists anyway and lower powered SQL Servers.

The nature of the data being collected and stored by Orion places a heavy I/O load on the SQL Server. Having logging set to Full Recovery only increases this load, and quite significantly.

There are alternative options for SQL Server replication, that do not require Full Recovery mode.

byrona

Marie

I am going to have to disagree with you just a bit. Any product that touts itself as Enterprise Class is essentially saying that it's fault tolerant, high speed, high reliability, and low downtime. I understand that Enterprise Class may not have a specific definition associated with it but I am confident that these are the things that the industry assumes when they see the term Enterprise Class.

Additionally, when we purchased the product nowhere in the documentation did it suggest that Full Recovery mode wasn't supported. I only found this out after many performance issues and finally speaking with one of the SolarWinds Database experts. After speaking with him he assured me that he would see that information get documented which is great news but that still leaves me in a very difficult situation.

I now have to explain to my executive management team that the Enterprise Class monitoring solution that we purchased and spent a year migrating everything to is not a low downtime solution. I really love the product but you are kind of leaving me out in the cold on this one and it's not a happy place for me to be.

I certainly hope you can understand my frustration here and see how I feel like I was a bit mislead on the whole Enterprise Class thing.

byrona

The advice given is correct for larger installations, which is usually where the DR failover requirement exists anyway and lower powered SQL Servers.
The nature of the data being collected and stored by Orion places a heavy I/O load on the SQL Server. Having logging set to Full Recovery only increases this load, and quite significantly.
There are alternative options for SQL Server replication, that do not require Full Recovery mode.

Dobbs

I would be interested in learning about what my other options are for SQL Server replication. A low downtime environment is critical as we are providing monitoring services to our customers using Orion with SLA's that we need to be able to meet.

If you know of some solutions I would be very grateful if you could share them with me, that goes for anybody else out there there that is reading this, thanks!

outernet

Byron,

Did you ever receive a satisfactory response to this inquiry? I agree with you that Enterprise software should be a 'low downtime' application. We too are an MSP utilizing SW to provide services to our customers. We had previously provided fault tolerance using an MSCS SQL cluster and very frequent backups. This scenario failed when the shared resource master database crashed and took down SW for about an hour as we basically rebuilt the SQL server to fix the problem. For this reason we decided to move to log shipping, and while searching thwack to see if SW supported Full Recovery stumbled upon your thread.

I have just purchased ridiculously fast hardware and disk IO for our new DB architecture. I'm just inclined to run in Full Recovery as I know the hardware resources should be able to handle the increased I/O of Full Recovery. Thoughts? And thanks in advance!

-jamie

byrona

I had an offline conversation with several people at SolarWinds regarding this very topic. It basically comes down to this...

SolarWinds doens't support or not support full recovery mode. If you call SolarWinds support and the problem looks to be database performance related they will point to the fact that you have it set to full recovery mode as a potential and likely problem and they will likely want you to change that before further investigation is done so that they can rule that out.

For a high availability environment for MSSQL they do recommend the solution provided by NeverFail. NeverFail is also the product that SolarWinds licenses for their FoE product.

This is the basic conclusion that I came to after speaking with several support and product management folks over at SolarWinds, I hope this helps.

dkobrosly

I'm curious as well...

njoylif

Mark, I too would be interested in hearing other alternatives. Would you please elaborate?

TIA!

Dobbs

m_roberts

Sorry for not replying to previous post.

The Neverfail for SQL solution performs file level synchronisation and therefore does not utilise the Transaction log. Other block level mirroring methods can also be used, but all of these I would suggest are not as good using full SQL replication techniques; Always on, Mirroring, etc.

Mark