SQL Tools :: In Simple Recovery Mode Can Do Live Differential Backup?
Jun 30, 2015
I have a small, ~10GB SQL 2008 R2 database, that was setup with simple recovery. We do full backup each night at midnight when no one is using the database. Is there any problems with doing differential backups during the day when users may be writing to the database? Could I even do hourly differential backups while users are using the database? I'm conflicted about switching over to full recovery mode and using transaction logs to have the ability restore data between backups. If I can do a couple daily differential backups while users are using the database during the day, in addition to our nightly full backups, than I live with simple recovery mode.
When we do a full database backup manually, we are seeing the trn file reflect the current date/time, but we are not seeing the mdf reflect the new date/time. And we are not seeing the transaction log file decrease in size. the recovery mode is set to full, do we need to change to simple to see both the mdf being backup'ed?
I have a database that is just over 1.5GB and the Full backup that is 13GB not sure how this is since we have compression on for full backups and my other full backups are much smaller than there respective databases...Now my full backup is taken every Sunday night and the differentials are taken every 6 hours after the full backup. Now I have been thrown into this DBA role with little to no experience just what I have picked up and read. So my understanding of backups are limited but what I think I understand is that we take a full backup and the differential only captures what changes in the database so my question is why is my database 1.5GB but my differential is 15.4GB? I have others database that are on the same instance and don't seem to have this problem. I also just noticed that we do not rebuild the index before a full backup like we do on other instances...
I have just begun to try out differential backups. Almost every reference I found on the internet said to use a .dif file extension. Books Online "Back Up Database Task (Maintenance Plan) MS.SQLCC.v9/MS.SQLSVR.v9.en/uirfsql9/html/ed1ef012-fa14-4ba5-bafe-d1527ba065b3.htm only says :
Backup file extension Specify the extension to use for the backup files. The default is .bak.
Using .dif for the differential shows "Microsoft Office Excel Data Interchange Format" as the type when looking at the backup folder. URL... indicates that .dif has 11 different uses, including "Difference data file." In a couple of posts in this forum in April and May of this year David Dye said that the file extension for differential backups is .bak, the same as for the full backup.
If this is the case, this would cause a problem with our maintenance plan policy which is to retain the two most recent backup files on the server. If we do a full backup for the base on the weekend and differential backups the rest of the week, our full backup would have to be restored from out tape system before we could do a restore. Recoveries are pretty rare, but when we get that panicked phone call that someone accidently deleted all the records of a major client, time is of the essence in getting that point in time restore done.
On SQL 2000, if I have a large transaction log for my database and I manage to fill it with a single large transaction but it is not set to autogrow, what happens?
I have several databases that perform daily backups. Ever since I installed SP2, the backup jobs are failing. The logs state that it's because the database recovery mode cannot be SIMPLE, but need to be either FULL or Bulk-Logged.
Can anyone tell me if this is true, and that I do have to change my recovery mode?
Here's the error:
NEW COMPONENT OUTPUT Microsoft(R) Server Maintenance Utility (Unicode) Version 9.0.3042 Report was generated on "ICIS-SQL-SERVER". Maintenance Plan: DB Backup Duration: 00:08:05 Status: Warning: One or more tasks failed.. Details: Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:09. Task end: 2007-03-10T05:08:09. Failed:(-1073548784) Executing the query "BACKUP LOG [hl7 db_SamirTesting] TO DISK = N'D:\mssql\backup\hl7 db_SamirTesting\hl7 db_SamirTesting_backup_200703100508.trn' WITH NOFORMAT, NOINIT, NAME = N'hl7 db_SamirTesting_backup_20070310050809', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Command:BACKUP LOG [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:09. Task end: 2007-03-10T05:08:09. Failed:(-1073548784) Executing the query "BACKUP LOG [dg_efilm_153] TO DISK = N'D:\mssql\backup\dg_efilm_153\dg_efilm_153_backup_200703100508.trn' WITH NOFORMAT, NOINIT, NAME = N'dg_efilm_153_backup_20070310050809', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Command:BACKUP LOG [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:09. Task end: 2007-03-10T05:08:09. Failed:(-1073548784) Executing the query "BACKUP LOG [hl7 db] TO DISK = N'D:\mssql\backup\hl7 db\hl7 db_backup_200703100508.trn' WITH NOFORMAT, NOINIT, NAME = N'hl7 db_backup_20070310050809', SKIP, REWIND, NOUNLOAD, STATS = 10 " failed with the following error: "The statement BACKUP LOG is not allowed while the recovery model is SIMPLE. Use BACKUP DATABASE or change the recovery model using ALTER DATABASE. BACKUP LOG is terminating abnormally.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
Command:BACKUP LOG [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP LOG [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100508.trn'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050809'', SKIP, REWIND, NOUNLOAD, STATS = 10
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:08. Task end: 2007-03-10T05:08:09. Failed:(0) Database 'hl7 db_SamirTesting' will not be backed up because it does not have its recovery model set to Full or BulkLogged.
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:08. Task end: 2007-03-10T05:08:09. Failed:(0) Database 'dg_efilm_153' will not be backed up because it does not have its recovery model set to Full or BulkLogged.
Back Up Database (Transaction Log) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All user databases Type: Transaction Log Append existing Task start: 2007-03-10T05:08:08. Task end: 2007-03-10T05:08:09. Failed:(0) Database 'hl7 db' will not be backed up because it does not have its recovery model set to Full or BulkLogged.
Back Up Database (Full) (ICIS-SQL-SERVER) Backup Database on Target server connection Databases that have a compatibility level of 70 (SQL Server version 7.0) will be skipped. Databases: All databases Type: Full Append existing Task start: 2007-03-10T05:00:06. Task end: 2007-03-10T05:08:08. Success Command:EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupmaster'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupmodel'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupmsdb'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackuphl7 db_SamirTesting'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackupdg_efilm_153'' GO EXECUTE master.dbo.xp_create_subdir N''D:mssqlackuphl7 db'' GO BACKUP DATABASE [master] TO DISK = N''D:mssqlackupmastermaster_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''master_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [model] TO DISK = N''D:mssqlackupmodelmodel_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''model_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [msdb] TO DISK = N''D:mssqlackupmsdbmsdb_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''msdb_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [hl7 db_SamirTesting] TO DISK = N''D:mssqlackuphl7 db_SamirTestinghl7 db_SamirTesting_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_SamirTesting_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [dg_efilm_153] TO DISK = N''D:mssqlackupdg_efilm_153dg_efilm_153_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''dg_efilm_153_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10 GO BACKUP DATABASE [hl7 db] TO DISK = N''D:mssqlackuphl7 dbhl7 db_backup_200703100500.bak'' WITH NOFORMAT, NOINIT, NAME = N''hl7 db_backup_20070310050006'', SKIP, REWIND, NOUNLOAD, STATS = 10
What is the impact of changing the recovery mode of a database from Full to simple? The client I am at has set their database to full recovery mode, set their log files to grow automatically. But I don't think they have ever done a backup of their transaction log (it has grown to over 19Gig, where the data portion of the database is only around 400M).
What is the impact of truncating the transaction log now? After truncating it, i would like to shrink the file to a managable number and change the recovery mode to simple (they don't need transaction log backups)
I missed the ability to restore based on a time (10/23 6pm) due to our purge cycle in our production environment, but I was able to obtain the 10/18 full backup, the 10/23 differential backup, and the 4, 10/23 trans. log backups. I moved all the fore mentioned files to a staging environment, and now I am trying to restore all of the files to 10/23 6pm and I get :
"The log or differential backup cannot be restored because no files are ready to rollforward" error.
hi, we have a SQL Server 2000 database which we set to 'SIMPLE' recovery mode at 6pm (due to nightly large data loads). We revert back to 'FULL' recovery mode at 6am.
My understanding was that in 'SIMPLE' recovery mode, the transaction log would not grow because it would automatically be truncated after a checkpoint. However this is not the case. I thought perhaps it could be due to a long running uncomitted transaction, but when I ran 'dbcc opentran', the oldest running transactions doesn't last for more than a couple minutes. I manually run a 'checkpoint' command as well in the hope of forcing the transaction log truncation. I repeat this a couple of times to no avail. When I run 'dbcc sqlperf(logspace)' , I can still see the transaction log growing.
It is not until I run 'backup log db with truncate_only' that the transaction log gets truncated. I do not understand, why the transaction log does not get automatically truncated in SIMPLE recovery mode?
My understanding is that the log file is not supposed to grow if the database is under simple recovery mode.I am in a situation where the log grows if do any inserts that involve millions of rows.How do i make sure that it does not grow?
Wondering whether I can have following included in a script file:
1. set the current single user db from Full to Simple recovery mode. 2. Checkpoint and shrink the transaction log file (release all unused space) 3. set the current single user db from Simple recovery to Full recover mode.
The DB is in simple recovery mode. There are no open transactions (used dbcc opentran).
The server is running SQL Server 2014 and the DB is in compatibility mode SQL Server 2008 (100). It was upgraded to 2014 a month or two ago.
I have tried to re-size the log to 100mb, but any way I have tried (none gave errors), the log file remains the same size. I have tied to shrink the log file (through the UI and via DBCC commands) without success; no errors, but also no change in file size.
I have checked Log Reuse Waits, just in case, and as expected it showed “NOTHING” (select log_reuse_wait_desc, name from sys.databases)
I tried running a checkpoint, but that did not allow any resize or shrink to work.
I have tied creating large transactions to move the used point in the log file, in case this was the issue. I did this by creating tables that I drop after large inserts. While it shows me that the log space % used increased, the log file still does not allow the space to be reduced.
The following is what I was using for the transactions to get the log used.
BEGIN TRAN select a.* into testtable from sysobjects a, sysobjects b, sysobjects c ROLLBACK TRAN
Do I just need to continue running large transactions until the log space used gets high enough to get the “end point” in the log to really move? Is there an easier way to accomplish this (I have several DBs that have the almost identical problem), what I am using moves the Log Space Percent Used about a percent on each execution.
We have a SQL Server 7.0 database running with trunc. log on chkpt andselect into/bulkcopy checked and need to develop a backup strategy.One of our DBAs insists that since the transaction log is beingtruncated, we can't do a hot backup (a FULL backup in multiuser mode)because if a transaction comes through during the backup it will leavethe backup in an inconsistent state. I'm skeptical, but I don't knowhow SQL Server 7 avoids this problem.If SQL 7 is not truncating the transaction log, it uses thetransaction log to roll forward changes that occurred during thebackup. Obviously if it's truncating the log it must have some way toapply these transactions anyway (such as not doing a checkpoint duringthe backup, backing up the log at each checkpoint, etc.).Can anyone confirm that a hot backup will be valid when trunc. log onchkpt is checked? Does anyone know how SQL 7 accomplishes this?Thanks!James
Pardon me and my ignorance for asking this question. I just want to understand the backup architecture more clearly. According to BOL (both in SQL 2k and SQL 2k5) in simple recovery mode trasaction log backup is not possible since the log is truncated on checkpoint which is true. Also we know that FULL backup backups both the db and transaction log as well.
My question is what happens when a database is in simple recovery mode and a full backup is done. since the tran log cannot be backed up does only the db backup is done when a full backup is done?. What exactly happens behind the scenarios?. Is it that only the active log gets backed up when a full backup is done in simple recovery mode?. I am trying to understand how a full backup in simple recovery mode behaves without contradicting the full backup architecture and that the veracity of the statement (both db and tran log backup in full backup mode) holds true for a simple recovery scenario.
MVPs/ MS Experts if you could Please explain it in detail, I would really appreciate it.
Using Ola Hallengren's scripts I do a full backup of a database on a Sunday. Then differential backups every 6 hours and log backups every hour. I would like to keep a full week of backups based off the full backup done on Sunday. Is there a way for me to clear out the diff and log folders after the successful full backup on Sunday nights?
I am using the Simple recovery model and I'm taking a weekly full backup each Monday morning with differentials taken every 4 hours during the day.
On Wednesday afternoon, a programmer ran a process that corrupted the db and I had to restore to the most recent differential. It was 5pm in the afternoon and a differential backup had just occured at 4pm. No problem, I figured.
I restored the full backup from Monday morning and tried to restore the most recent differential backup. The differential restore failed. Since I had used T-SQL for the initial attempt, I tried using Enterprise Manager to try again.
When viewing the backup history, I see my initial full backup taken on Monday plus all the differentials. BUT, on closer inspection, I noticed another full backup in the backup history that was taken early Tuesday morning. I can't figure out where this Tuesday morning full backup came from. It wasn't taken by me (or scheduled by me) and I'm the only one with access to the server. My full backups are usually named something like HCMPRP_20070718_FULL.bak. This erroneous full backup was named something like HCMPRP_03a_361adk2k_dd53.bak. It seemed like it was a system generated name. Not something I would choose. To top it off, I could not find this backup file anywhere on the server and when I tried to restore using this full backup, it failed.
Does anyone have any clues as to where this full backup might come from? Does SQL Server trigger a full backup on its own if some threshold is reached?
I ended up having to restore using the differential taken just before this erroneous full backup and lost a day of transactions.
I am running SQL Server 2005 x64 Enterprise under Windows 2003 x64 Enterprise. My current backup strategy uses T-SQL jobs run by SQL Agent (writes out *.bak files) and then I have an Integration Services job that copies the *.bak files to our NAS device. I have performed a restore without issue. The jobs are all automated every four hours via SQL Agent. Is this a sound strategy or are there additional benefits to using 3rd party tools? If so, what are the advantages and which tool provides them?
Using SQL Server 2005, we have a 2.8Gb database under the Simple recovery model. The database contains ~50M rows and each night ~60k rows are loaded(appended) to the database by a SSIS task.
We configured a Maintenance Plan which is executed once a week to perform a full backup of the database. The resulting backup file is ~2.8Gb, as expected.
We also configured another Maintenance Plan which is executed every day, a few hours after the SSIS task is executed, to perform a differential backup. To our surprise, the resulting backup file is about the same size as the full backup, ~2.8Gb when it should only be a few MB (only 60k rows are added to the database)
When we launch the "Restore Database" wizzard we clearly see the different backup set, Full and Differential but they all have about the same size (same for the physical backup file on disk).
Is there anything we are missing, why are the differential backup that big?
Thru maintenance plan I backup my DBs every night and the T-Logs every hour. Now I have to set the option "select into/bulk copy" on one DB. I schedule the differential backup every 3 hour with option "overwrite existing media", wich is, in my case, one file on disk. My sequence of T-Logs is valid even if a non logged operations occurs? If I have to restore this DB can I use the last full backup + the differential backup + all the logs in between?
I trying to created a Differential backup and I get the following error. Can anyone help?
The volume on device 'd:MSSQL7BACKUPCPIDATABKUP.BAK' is not part of a multifamily (RAID) media set. Use WITH FORMAT to form a new RAID set. [SQLSTATE 42000] (Error 3259) Backup or restore operation terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.
I'm trying to create a differential backup job that run hourly and that creates a different differential files. Ext. dbfilename1am, dbfilename2am, dbfilename3am ect... Can I do this with one job? Are do I have to create a differential backup job for each hour?
I've defined a maintenance plan in SQL2005, which creates a differential backup of a DB daily. Suppose I'm having differential backups from May, 10 to May, 14 but backup files of May 12 and May 13 are lost (deleted unexpectedly). Am I losing some data, if I restore from backup file of May 14?
I asked question while back about Log PI tool, it did not get any replies but I found out it is no longer supported and developed. Now I would like some feedback about other tools that can help with log recovery. I heard about Lumigent, Red Gate and Apex SQL. Any more alternatives? Also I would like your feedback about customer support, pricing, updates, features etc.
I need to replication a server database out side a firewall. But can't change the server configuring for replication, so replication is out. So I wanted to know if I have a full backup of every db send to me every 24hrs. W/ differential every hr, will the restoring process work on the restoring server? Should I restored the full 1st? I'm not sure if the restoring of the Differential will work. Any help on the steps to take, to get this to work with backups & differential will be greatly appreciated.
I'm trying to run a differential backup on our new 7.0 box. It fails with an error message number 3242 "The file on Device 'E:MyFile' is not a valid Microsoft Tape Format backup set."
Why "Tape Format" if I said "Backup database [mydb] to disk"?..
When I run exactly the same query without "Differential" I got a full db backup.
When a new scheduled job is created for a Differential backup, the file specified in the Destination folder is automatically created by SQL Server. After the first time the job runs, is there a way to configure SQL Server to give each Differential file a unique name, including the timestamp (i.e. similar to Full Backup jobs)? I noticed my only options are 'Append to File" and "Overwrite Existing File." If I choose to enable "Backup Set Expiration," the backup job will not run, because it wants to append/overwrite the filename specified.
