Different RPOs on same VM?

[bhagen]

We have a main SQL DB server (vmware VM, windows server 2012) with 15 DBs, and currently we're doing a nightly forever-forward backup with 30 restore points.

We're adding a couple new DBs that need a larger set of restore points (90 days).

How would I go about keeping backups of only those 2 DBs longer than the rest of the VM?

I read in this post veeam-backup-replication-f2/backing-up- ... 55904.html that the only way to backup individual DBs is to install the Windows Agent, and do a "Windows computer" backup of those individual files.

Is that still the only way to do it today, with VBR v10?

If so, can I install the windows agent on this machine, continue to do "regular" nightly backups, but additionally create an agent backup for just those 2 DBs?

[Gostev]

It's certainly an option. But I think it will be much easier to use NAS Backup jobs in Veeam Backup & Replication v10 to backup files behind those two databases. Thanks!

[bhagen]

I've not explored NAS backup jobs because we're running VSAN...and I'd heard a while back that VSAN isn't supported?

So I did a quick search, and found this...which seems very complicated and time consuming, if it even works on VSAN. All this work for 2 DBs *may* not be worth it...

"To enable and configure the NAS backup feature in Veeam Backup & Replication, add the following components to the backup infrastructure:
File share
File proxy
Cache repository
Backup, archive, secondary repositories"

Please digest the next 50 pages of instructions to continue.

[Gostev]

It does not matter where your database VM is hosted (VSAN or not), because backup will be done directly from within the guest OS.

As for the rest, I'm happy to unveil this for you.

1. Adding file share is required because this is where you're backing up from. Obviously, there's no way to create a backup of some files without registering the actual source of files. In your case, you will need to register the database server itself.

2. The default File Proxy should already be pre-created for you (your backup server), so you don't need to create one unless for redundancy and scale. However, in your case you won't need to use file proxies in principle, because your data source will be a server (not a share).

3. For cache repository, you just specify any existing repository, no need to create anything new. Again, the default backup repository is always pre-created as well (your backup server), but I'm sure you already have your own repositories created.

4. You don't need to specify archive or secondary repositories if you don't need archiving or secondary copies of backed up database files. But of course, you do need to specify the backup repository, because you need to identify a target for your backups.

And there's no 50 pages either, actual file backup wizard is just a few steps long, and is where you specify essential stuff like job schedule or retention. There's really no way around this, no matter how you end up performing those backups.

All in all, I would say NAS Backup is at least 3x simpler than agent-based VM backup in terms of configuration, just because there are 2x less options to specify and no requirement for creating Protection Groups.

I'm sure you will agree once you try it.

[bhagen]

Interesting; thanks Gostev! I was referring to the Veeam documentaion pages, not the wizards. I also mis-understood, and thought I was going to have to purchase / configure / physically install new cache and secondary repositories...it didn't occur to me that I could specify my current repositories.

Guess I just needed more coffee this morning!

So, back to the original question then, a bit modified: Can I keep doing my regular backups of the entire VM, and create another (file share) backup of just those two DBs? (The DBs are in their own folders on the d: drive.) Or, is there a better way to extend the amount of restore points for those 2 specific DBs?

[Gostev]

Yes, this is what I would do: keep doing regular backups of the entire VM + create another (file share) backup of just those two DBs. I don't see really see any other options, since your primary backup is image-level, meaning retention can only be image-level too.

[bhagen]

Thanks!

[bhagen]

Well, I'm still struggling with this; the file copy method keeps failing. I'm not sure if the error is telling me that it's failing because the DBs (files) are in use, or because some "other" file is in use:

Code: Select all

6/10/2020 7:35:11 PM :: Failed to prepare VSS resources, skipping snapshot processing Details: Failed to call RPC function 'HvGetVolumesByPaths': The process cannot access the file because it is being used by another process. Failed to open file [D:\DataBase\DB100.mdf] in readonly mode.  

I can open a ticket if this is too much troubleshooting for the intent of this forum.

[Gostev]

Yes, you should open a support case as we can't troubleshoot issues via forum posts. It looks like Microsoft VSS snapshot creation process is failing for some reason.

[bhagen]

I figured that'd be the way to go, so I opened Case #04226067. I'll post the solution(s) here if appropriate.

[Matts N]

Can a file share backup be application aware? Handle transaction logs? Just a thought, my guess would be "no" to both these questions, maybe should factor that into the decision of which path to take. I don't know how large the other 15 DB's, so have no clue how much space storing them for 90 days instead of 30 would "cost".

[Gostev]

It does use Microsoft VSS to ensure the consistency of backed up files. But being a file-level backup, it does not have application-aware processing logic like detection of a database server, enumeration of databases, running a sub-process to capture and ship transaction logs periodically, etc. These are the features of the entire computer backup.

[mervincm]

The loss of the full SQL quiesce might be enough to consider talking to the DBA and just have them do a regular SQL side backup for these two databases to file. They could do that on a 60-day circular basis. The files could be stored right on this SQL server, and they would be protected in the existing backup. 30+60 gets you your 90 days.

[bhagen]

Thanks for all the suggestions; after long discussions with the team this morning, and after being on the phone with support for an hour with no solution in site, we've made the decision to just move the two DB's in question (and any future "forever" DBs) to a new SQL server, and do "forever" backups of that entire server. Much easier to manage backups that way. I've closed the ticket.

On to more pressing matters...like, coffee.