August 25, 2014 at 12:05 pm
Background:
select
backup_start_date
, type
, recovery_model
, server_name
, machine_name
, first_recovery_fork_guid
from msdb..backupset t
where database_name = 'myDB'
and t.backup_start_date >= '2014-08-11'
order by backup_start_date desc
backup_start_datetyperecovery_modelserver_namemachine_namefirst_recovery_fork_guid
8/25/14 10:12 AMDSIMPLEmyDEVmyDEVguid_1
8/25/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/24/14 11:30 PMDFULLPRODPRODguid_2
8/24/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/23/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/22/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/21/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/20/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/19/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/18/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/17/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/16/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/15/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/14/14 12:00 AMDFULLmyDEVmyDEVguid_1
8/13/14 12:00 AMDSIMPLEmyDEVmyDEVguid_1
8/12/14 12:00 AMDSIMPLEmyDEVmyDEVguid_1
8/11/14 11:29 AMDSIMPLEmyDEVmyDEVguid_1
8/11/14 12:00 AMDSIMPLEmyDEVmyDEVguid_1
Meanwhile, on PROD, a full backup was taken on Aug 13 during the day. This is what appeared to have triggered the switch on DEV from SIMPLE to FULL, even though the PROD backup is not reflected in the DEV MSDB.
Much obliged if anyone has an idea about how PROD backups exhibit some type of persistence (presumably owing to the RESTORE/REPLACE operations) in our DEV MSDB, and which subsequently appear to affect the DEV recovery model.
Thanks,
John
August 25, 2014 at 12:11 pm
Backup processes will not change the recovery model of a database. The only way this can happen is if someone goes in and manually modifies the recovery model using either T-SQL or the GUI interface.
August 25, 2014 at 12:18 pm
Thanks Lynn - I'll have to do some more digging then. I'm still suspicious though since no one else would think to alter the RM and I definitely didn't ...
:unsure:
August 25, 2014 at 12:22 pm
Lynn Pettis (8/25/2014)
Backup processes will not change the recovery model of a database. The only way this can happen is if someone goes in and manually modifies the recovery model using either T-SQL or the GUI interface.
But RESTORE WITH REPLACE certainly would change RM (as I alluded to on my OP)...
August 25, 2014 at 12:24 pm
Quick look and one major concern, only one production backup showing in the period of two weeks!
😎
August 25, 2014 at 12:35 pm
Yes, thanks for the sanity check -
Actually I'm running Mr. Hallengren's scripts on PROD. 1 weekly full, daily diff, hourly log -- works a charm!
The other thing to note, which IS curious, is why PROD backup shows up on my DEV MSDB (that's what I'm displaying above)!!!
August 25, 2014 at 12:38 pm
jjturner (8/25/2014)
Lynn Pettis (8/25/2014)
Backup processes will not change the recovery model of a database. The only way this can happen is if someone goes in and manually modifies the recovery model using either T-SQL or the GUI interface.But RESTORE WITH REPLACE certainly would change RM (as I alluded to on my OP)...
But that is a RESTORE process not a BACKUP process. Yes, if the database you are restoring had the recovery model set to FULL, upon restore it will be FULL even if the database it is replacing had been set to SIMPLE.
August 25, 2014 at 12:40 pm
Eirikur Eiriksson (8/25/2014)
Quick look and one major concern, only one production backup showing in the period of two weeks!😎
I think you've just scoped your investigation here, suspect that somewhere there is a mis-configuration.
😎
August 25, 2014 at 12:49 pm
Yes, apologies for the tacit generalization (backup ~ backup/restore)
So further to the point, I'm having this DEV recovery model switch over to FULL a number of days after it got restored from PROD on Aug 6th - and as I tried to illustrate from the backupset, it was backing up as SIMPLE after the Aug 6th restore (because I manually switched it back to SIMPLE after the RESTORE), until it mysteriously switched to FULL recovery on Aug 14th...
August 25, 2014 at 12:54 pm
jjturner (8/25/2014)
Yes, apologies for the tacit generalization (backup ~ backup/restore)So further to the point, I'm having this DEV recovery model switch over to FULL a number of days after it got restored from PROD on Aug 6th - and as I tried to illustrate from the backupset, it was backing up as SIMPLE after the Aug 6th restore (because I manually switched it back to SIMPLE after the RESTORE), until it mysteriously switched to FULL recovery on Aug 14th...
Quick question, how many developers have the permission to do this?
😎
August 25, 2014 at 12:57 pm
Eirikur Eiriksson (8/25/2014)
jjturner (8/25/2014)
Yes, apologies for the tacit generalization (backup ~ backup/restore)So further to the point, I'm having this DEV recovery model switch over to FULL a number of days after it got restored from PROD on Aug 6th - and as I tried to illustrate from the backupset, it was backing up as SIMPLE after the Aug 6th restore (because I manually switched it back to SIMPLE after the RESTORE), until it mysteriously switched to FULL recovery on Aug 14th...
Quick question, how many developers have the permission to do this?
😎
5 people
August 25, 2014 at 1:08 pm
jjturner (8/25/2014)
Eirikur Eiriksson (8/25/2014)
jjturner (8/25/2014)
Yes, apologies for the tacit generalization (backup ~ backup/restore)So further to the point, I'm having this DEV recovery model switch over to FULL a number of days after it got restored from PROD on Aug 6th - and as I tried to illustrate from the backupset, it was backing up as SIMPLE after the Aug 6th restore (because I manually switched it back to SIMPLE after the RESTORE), until it mysteriously switched to FULL recovery on Aug 14th...
Quick question, how many developers have the permission to do this?
😎
5 people
Possibly that's 5 too many, you may want to use a friendly educational approach like "if you do this again I'll break your..."
😎
On a more serious note, would there be a reason for any of these five to change the settings? Could it be a case of mistaken identity thinking it was the production environment (seen that happen)? Connection properties in Registered Servers within SSMS have an option of colour coding, good tool to prevent that kind of mistake.
August 25, 2014 at 1:20 pm
Eirikur Eiriksson (8/25/2014)
jjturner (8/25/2014)
Eirikur Eiriksson (8/25/2014)
jjturner (8/25/2014)
Yes, apologies for the tacit generalization (backup ~ backup/restore)So further to the point, I'm having this DEV recovery model switch over to FULL a number of days after it got restored from PROD on Aug 6th - and as I tried to illustrate from the backupset, it was backing up as SIMPLE after the Aug 6th restore (because I manually switched it back to SIMPLE after the RESTORE), until it mysteriously switched to FULL recovery on Aug 14th...
Quick question, how many developers have the permission to do this?
😎
5 people
Possibly that's 5 too many, you may want to use a friendly educational approach like "if you do this again I'll break your..."
😎
On a more serious note, would there be a reason for any of these five to change the settings? Could it be a case of mistaken identity thinking it was the production environment (seen that happen)? Connection properties in Registered Servers within SSMS have an option of colour coding, good tool to prevent that kind of mistake.
I suppose I'll have to resign myself to accept that this was accidental human intervention and not some bizarre system-induced change. (Although that still doesn't explain why PROD backups are showing up in my DEV msdb backupset...)
My gut still tells me that swapping the database backwards and forwards between DEV and PROD has given my DEV instance a case of indigestion...
But thanks for the connection properties tip, I'll see if I can put that into effect.
Cheers 😎
John
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply