Azure Recovery Services and SQL 2014 Managed Backups not playing well together
Asked Answered
C

2

11

I started using Managed Backups on my SQL server. It has been working well for over a year. It seems to backup the dbs once a week, and take incrementals every 2 hours.

A month ago, we changed our VM backup solution to Azure Recovery Services. We started running it every night. When Azure Recovery Services runs in the evening, it looks like, from the Windows and SQL logs, it takes a backup of each database before it does a volume shadow copy. They are entered into the logs as TYPE=VIRTUAL_DEVICE: and a big GUID, and a new database lsn number is created. When this VM backup occurs my weekly Managed Backups are invalidated.

When I look in the msdb.dbo.smart_backup_files table where the SQL Managed Backup stores its records to keep track of its backups, I can see there are 2 fields that seem to be important. backup_type. When this equals 1 it is a full backup, and when it is a 2 it is a log. The next field is the backup_database_lsn. This field represents the full backup that the log can be applied to.

When the SQL Managed Backup runs its full backup once a week, a new lsn number is created, and every log file that is created afterwords, has a value in the backup_database_lsn number that points back to that lsn number of the full SQL Managed Backup for that week.

Now, when Azure Recovery Services runs nightly, a new full database lsn number is created from the TYPE=VIRTUAL_DEVICE line in the logs. When I look in the Managed Backup table (msdb.dbo.smart_backup_files) I can see that all then subsequent log files that used to point to the Managed Backup's full lsn number now point to the new lsn number for the VIRTUAL_DEVICE of the Recovery Services backup.

If I need to do a restore of the Managed Backups, I can only get the full backup and 1 days worth of logs. After that, all of the log files now point back to the Recovery Services VIRTUAL_DEVICE backup, which doesn't really exist.

I have looked for the VIRTUAL_DEVICE backup. When I open a database through Enterprise Manager, and click on Restore for a database, it pulls up the most recent full backup (in this case the Recovery Manager full backup), and its log files. If I click on the full backup entry, it believes the file is in the SQL Server backup folder with the name of the file being the GUID. That file does not exist, or it may exist in the night VM backup which I can't view in Azure Recovery Services. Either way, my weekly Managed Backup is invalidated for the rest of the week.

Does anyone know how to make these two work together? I would like to have a full VM backup in case something bad gets installed on the SQL Server and we need to do a full restore, and I'd like to have a weekly full backup with incremental log files in case we need to restore one database.

Constrict answered 24/2, 2017 at 12:32 Comment(2)
You might find more expertise on dba.stackexchange.comMedrek
Would a full backup each day be good for you (in term of permances also)Defame
A
0

It sounds as if what you are looking for differential backups. Those would contain everything added to the database following the last full backup.

I.e. you take a full backup on Sunday evening, with a differential backup every day after. On Monday evening, your differential backup would contain everything added since the backup. On Tuesday, it'd contain everything it contained on Monday, as well as everything changed since then.

If you'd do the same using Transaction Log Backups, your Monday evening backup would actually be identical to the differential backup described above. However, the Tuesday version of the Transaction Log backup would only contain the changes from the time of the Monday transaction Log backup.

When it comes to restoring, this would mean that in order to restore to a point in time, you would have to restore the latest Full Backup (Sunday), followed by every transaction log backup since, in sequence (Monday, Tuesday, etc.).

Using Differential backups, though, you would restore the latest Full Backup (Sunday), followed by the latest Differential Backup (Tuesday, if you're restoring on Wednesday).

Aloin answered 30/5, 2017 at 11:1 Comment(0)
H
0

When this VM backup occurs my weekly Managed Backups are invalidated.

This is wrong, no one full backup is invalidated by taking other full backup, what your newly added backups do they change the differential base so they could affect your differential backups but you don't use them.

Your log backup chain is not affected even if you see the database_backup_lsn reported in that log backups changed: it just shows the most recent full backup lsn but it does not mean that you have to start your restore from this full backup and SSMS just shows you the simplest (shortest) way to do the restore.

However nothing is changed (SSMS automation apart),

and I'd like to have a weekly full backup with incremental log files in case we need to restore one database.

You still be able to do this but you should manually create the correct restore chain from your Managed Backups just excluding other backups

Holmen answered 4/3, 2024 at 15:45 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.