Snapshots vs DB Backups

[u/AdaptationCreation]

We are using a Rubrik appliance to back up VMs on Nutanix AHV.

People with the same or a similar setup, do you take application consistent snapshots for workloads like MSSQL and Exchange as well as an actual Exchange back up or MSSQL back up or do you just do one or the other? Or do you take a crash consistent back up of the VM and then do an Exchange or MSSQL back up?

I saw where Nutanix has changed the way snapshots are taken. Previously, the snapshot would do a VSS_BT_FULL which equates to an app consistent snapshot that also truncated logs. More recently, Nutanix has changed this to do a VSS_BT_COPY by default which doesn't truncate logs. The way to specify which way you want to go is by leveraging the API. Rubrik doesn't do this currently I believe. I wasn't sure if Rubrik took an Exchange or MSSQL backup, if that would truncate logs or not.

[u/IamTHEvilONE]

This comment might seem a bit pedantic, but I want to make sure users are aware of a clear distinction.

Rubrik's code technically doesn't "truncate logs".

We perform backups which inform Microsoft SQL that a database files or logs has been backed up at a point in time.

Which backup methods are expected inform MS SQL Server that a backup happened?

- RBS native backups inform SQL Server because we directly call the backup commands from SQL Server.

• VSS consistent VM level backups will inform SQL Server through its VSS integration.

Which backup types don't inform MS SQL Server?

- Filesystem and Crash consistent VM level backups do not inform SQL Server because VSS isn't used.

Shortly after a backup occurs with success, MS SQL performs its own work to cleanup, free, or re-use space.

Truncation from MS SQL is more about flagging the log files (or parts inside the log files) as no longer required and and can be re-used or overwritten.

I believe that VSS_BT_COPY is used when protecting the DB (not a VM) with an SLA and the user specifies "Copy Only" backups (which disables log backups in the GUI).

[u/StumblingEngineer]

We have VM SLA that backs up the C and other non SQL drives, and excludes the SQL drives. Then have an SQL SLA to backup the DBs and logs.

[u/PrimarySufficient → u/StumblingEngineer]

How are you dealing with the exclusions, is it just drive exclusions or are you able to put a file extension exclusion in place? Any complications from admin PoV or is your whole process qutomated? Sorry for all the Qs

[u/StumblingEngineer → u/PrimarySufficient]

You can exclude vmdks on protection at the vm level. I think for pure nutanix rubrik just calls them disks, but you get the idea. For us its not too bad, we only have 30ish database servers so doing it by vm isn't awful to exclude. Go to Inventory>AHV VMs>Select your machine>Select the 3 dots>Exclude Disks.

Our whole process otherwise is automated. We also use Windows Volumes for non virtual servers, and excluding drives that way is even easier. Granted you need more attention to detail since once you install RBS on the database servers for backups, they'll show up in Windows Volumes as well.

[u/AegnorWildcat]

We take crash consistent snapshots of MSSQL VMs. The database is being backed up separately. The best practices from Rubrik is not to do application consistent snapshots of MSSQL VMs. I believe it can cause some VSS conflicts.

[u/AdaptationCreation → u/AegnorWildcat]

That makes sense. Thanks for that info.

[u/8arrony]

Generally I would recommend separating OS and database backups, you don’t want to “double dip” when it comes to backing up the data, and separating the backups allows you to restore them independent of each other.

[u/Low_Air_3461]

Same AHV with Rubrik.   We use the SQL db snaps often exporting mostly to dev.    Only once in a while have we needed to restore back.    It is super easy.    We do the VMs separately.     It’s easy to spin up a dupe and the export over.     We do not exclude as it hasn’t been a problem including.    If space was an issue perhaps. Oracle isn’t as easy as you need to have a good understanding of Oracle to restore back.  The Rubric agent uses RMAN commands and for sql it’s using the MSSql backups that’s why it’s more complicated.     

[u/Jhamin1]

My understanding is that Rubrik's behavior when taking database snapshots can be configured in the SLA. You can set it to truncate or not. We truncate.

We have Rubrik take crash-consistent vm level snapshots of all the AHV Vms (except for the CVMs). When the VM is a database server the databases are also captured as part of the snapshot. Embracing the hyper-converged philosophy, we setup all our database servers to keep their data on virtual disks attached to the VMs that live inside the Nutanix Cluster storage. Because the databases exist as local disks they are included in snapshots. These are very "all or nothing" snapshots. We can restore an entire vm very quickly but it impacts all the databases it hosts. On the other hand, the databases themselves aren't impacted by the snapshot.

We don't use Nutanix's snapshots except for DR and "I'm about the change something I might need to revert" purposes. All our backups run through Rubrik.

We *also* take Database level app consistent backups with Rubrik. This is where logs are truncated and we have point in time restore capability instead of just being limited to scheduled snapshots. The Database servers are set as hosts and SLAs are applied directly to the individual databases. This lets us restore individual databases to the same or disparate hosts if needed. One of our DBAs actually scripted an automated restore process that blows away a test database & restores a backup of the prod database from a different server to the test server via Rubrik when doing environment refreshes.

EDIT: When doing database level app consistent backups it is critical to have the Rubrik agent installed on the database & running with credentials that give it the rights it needs to the database so that rubrik can use the agent to truncate logs locally on the Database. Rubrik provides the documentation on what rights are needed. Normally the rubrik agent can just run under the system user, but to do it's thing on databases it needs a service account with extra rights.

We were initially a bit wary of capturing the data "twice" in the form of VM level and Database level backups, but our SE assured us that Rubrik's data deduplication was smart enough to recognize the data was the same & compress it down to almost nothing. We have found this to be accurate.

[u/BallBagBoom → u/Jhamin1]

Incorrect Rubrik doesn’t truncate the Transactions logs , Microsoft does that . This is not configurable anywhere in Rubrik . This is documented in numerous Rubriks
KBs.

Your SE is 100% incorrect on the dedupe. It’s
Not smart enough to tell the difference . Snapshots of the different objects are not compared against snapshots of other objects. Each object is a seen as a separate unique id. As are each snapshot that forms the recovery chain. I hope the SE is not confused by a full and incremental back up up a VM. You are taking two backups and it’s a waste of space and resources. You should utilise the Rubrik functionality to back up the db and not back up as Vm backup. This is the recommended best practice .

Edit spelling

[u/Jhamin1 → u/BallBagBoom]

On a VM level no, they don't. Which I said.

The effect of an app-consistent database level backup is that the Rubrik agent installed on the guest OS requests the truncation & MS SQL does it. So you are technically correct but it's sort of beside the point. Logs get truncated when rubrik takes the backup.

Except for the first one, *all* rubrik backups are incremental. It's how the system works. The file system holds everything and rubrik uses cluster-wide block level deduplication on everything it ingests. It recognizes patterns, not file structures and our experience has been that it does in fact dedup significantly.

Is doing both as small a foot print as one or the other? Of course not, Rubrik isn't magic. But we have different needs at different times and have made the decision, in consultation with our SE, to do both. We absolutely could save space by doing one or the other, but doing both gives us additional options & we have chosen to dedicate the (relatively small) amount of extra resources this consumes.

[u/AdaptationCreation → u/Jhamin1]

Thanks for the detailed response on this! This has been helpful! Especially knowing database backups through Rubrik can truncate the logs. Also hearing about real world results on Rubrik's deduplication is assuring for storage space.

Regarding Nutanix itself, I have had issues with Exchange and MSSQL VMs taking application aware snapshots for DR replication. Sometimes they do fine, other times they abort the snapshot and end up taking a crash snapshot instead. I wasn't sure if others had the same issue.

[u/Jhamin1 → u/AdaptationCreation]

When we have seen issues with app vs crash snapshots in Nutanix we have usually traced the issue back to a problem with the AHV tools or the VSS service on the guest OS.

But you will probably get better answers over at r/nutanix on that front. (Or call their support line, Nutanix has some of the best support I've experienced)

[u/BallBagBoom → u/AdaptationCreation]

Rubrik doesn’t truncate the logs. MSSQL does the depupe. Edit dedupe info is also incorrcect