We have several SQL Server 2008 R2 databases for which we perform a full backup every Sunday then differential backups Monday to Saturday. We also do transaction log backups every 10 minutes.
The first differential backup on Monday is usually quite small, but Tuesday to Saturday are much larger but similar in size to each other.
I used some scripts I found which predict the differential backup size, e.g. https://dougzuck.com/sql-differential-backup-size-prediction and http://www.sqlskills.com/blogs/paul/new-script-how-much-of-the-database-has-changed-since-the-last-full-backup/, and they predict a very much smaller backup size.
Examples are:
database1, full backup size 5Gb, diff size 3.5Gb, predicted diff size 84Mb
database2, full backup size 40Gb, diff size 1Gb, predicted diff size 17Mb
As you can see, the actual sizes are hugely different and can be half the size of the full backup after only a couple of days.
I know users aren't creating or modifying the actual data to any great extent. As far as I can tell, there are no index rebuilds or other management tasks happening between the full and differential backups.
It's like something is happening on Monday which causes the Tuesday onward differentials to be huge. Backup compression is not used.
Any ideas?? Thanks in advance.
Doug
How differential backup works..?
Whenever we take a differential backup,it copies all the changes which occured from last full backup,Not from Last differential backup..
That is the reason why you are seeing "actual sizes are hugely different and can be half the size of the full backup after only a couple of days"
Related
I setup a SQL Server maintenance plan as follows:
Full backup every Sunday at 2am
Differential backup every 3 hours
After the full backup was taken, I noticed the differential backups are varying in size. At first it started out small and grew accordingly. However, at various points, some differential backup file sizes may be larger or smaller than before. This includes big differences (i.e. 200MB to 3MB). I know that no other full backups have been taken nor has any large amount of data been deleted during those times. What would be the cause and is there something I am missing? Based on the research I've done, the differential should do nothing but increase until another full backup is taken.
Any insight would be appreciated.
Thanks!
Are you talking about differential backup or differential partial backup? What you describe looks a lot like differential partial backup. Differential partial backup were introduced with MSSQL Server 2005 and are very similar to incremental backup.
With differential partial backups only the changes since the last partial differential backup are kept. That means two things :
the file size of differential partial backup will vary according to the amount of changes in the database since the last differential partial backup.
if you want to restore a backup you have to restore the full partial backup (the base) and then every differential partial backup file.
Here is a very complete and interesting article about MSSQL partial backup.
Edit
The terminology used is a little confusing. In Microsoft documentation it is called partial differential backup (even though it works pretty much like an incremental backup) and to do that you have to use the very intuitive READ_WRITE_FILEGROUPS flag. AFAIK, you have to use T-SQL commands like :
BACKUP DATABASE [SampleDB] READ_WRITE_FILEGROUPS
TO DISK = N'C:\SQLBackups\SampleDB_PARTIAL_Diff.bak'
WITH DIFFERENTIAL
GO
I am working with a data warehouse with SQL Server 2012 and was wondering what would be the most optimized, automated procedure for a backup/restore strategy.
Current observations and limitations:
1) Cannot use transaction logs as it would affect my load performance - datasets are potentially huge with large transactions
2) Current plan is to do full backup every week and differential backup every day
I am not sure when DML operations will happen as it depends on my application's usage, but is there a way to just track the NUMBER of changes to a database that would trigger a differential backup? A way that would not affect performance? I do not want to be taking unnecessary differential backups.
Would Change tracking be a good solution for my scenario? Or would there be overhead involved? I do not need to know the actual data that was changed, just the fact that it was changed by a certain amount.
Thanks in advance!
Well, there's this ( http://www.sqlskills.com/blogs/paul/new-script-how-much-of-the-database-has-changed-since-the-last-full-backup/ ). I'm just trying to figure out what problem you're trying to solve. That is, if you find that the size is below some threshold, it will be (by definition) cheap to do.
It all depends on your DWH configuration.
1. Is your DWH database partitioned? If yes, It would be easier to do the daily db backup(diff backup) for the current partition ONLY. It's much more smaller set of data to be backed up.
If not, Current plan is to do full backup every week and differential backup every day is the only way since you cannot use transaction log file.
You could also try 3rd party disk (block) level backup software (i.e. Doubletake)....
Hope it helps.
You seem to have a mistaken notion of what a differential backup is. Don't worry; it's common.
When you say things like "track the number of changes to a database that would trigger a differential backup", it implies that you think that a differential backup gets all of the changes since the latest full or differential.
However, a differential backup gets all of the data that has changed since the last full backup only. So, you'd expect the size of subsequent differential backups to get larger and larger. For example, let's say you take a full backup on Sunday and a differential backup every other day. You'd get something like:
Monday: All of the data changed since Sunday's backup.
Tuesday: All of the data changed since Sunday's backup (including Monday's data)
Wednesday: All of the data changed since Sunday's backup (including Tuesday's data)
etc
Additionally, you'd only ever restore at most one differential backup if/when you need to restore your database. For instance, if your database crashed on right before Thursday's backup, you'd restore your last full backup (from Sunday in my example), then Wednesday's differential, and you're done.
As for when to schedule it, that's typically dictated by the rhythm of your business. For instance, you might decide to take a backup just before you kick off your ETL or just after. Doing it during doesn't make much sense as you'd have an inconsistent (with respect to your ETL process) database if you ever need to restore it.
I have a sql server 2008R2 DB with FULL recovery.
A full backup done nightly at 2am (overwriting the previous night's .bak file)
Every hour I have a Transnational backup .trn files
The last full backup was done today at 3am Sept 21.
Today I was asked to make a copy of the database to a previous time Sept 20th 12PM.
I know how to restore from an older last full backup (say Sept 20 3am) and then apply the .trn files to bring it up to a certain point in time (backup with norecovery then apply trns).
But is it possible to go backwards in time in my situation given that the only full backup I have was taken 3am Sept 21st? if not please tell me how I can change my backup strategy to be able to do it in the future if I run into this again.
thanks
Not knowing much about your organization needs
I would suggest taking a FULL Backup every night.
Differential Backup every one hour and then transaction backup every 10 to 5 mins or
whatever suits your organization needs best
and SET Expirydate for your backups for 5 to 7 days so that new backup will not overwrite the backups for so many days.
I think if you make a Backup strategy for your databases like this it will be helpful in future to go back in in time.
One more tip "A LESSON learnt the hard way" DO NOT FORGET to backup (master, model, msdb)
even once a week but make sure you have some sort of plan in place to backup these database.
I hope this reply will be helpful
Regards
Mo
I have a production system running on an SQL Server 2008 DBMS, in Full recovery mode.
I take a full backup each day at midnight, a log backup every two hours, and a differential backup every 6 hours (06:00, 12:00, 18:00, but not midnight as the full is taken then).
In recent days however I've noticed that the diff backup filesize of 18:00 is smaller than the one of 12:00. And sometimes, the one of 12:00 is smaller than the 06:00 ...
I did not experience this behavior until recent days.
Reading from the Microsoft doc, the filesize of a diff backup should always be larger than the previous one, until a new full backup is taken.
Could anyone have a possible explanation what could be causing this ?
Thanks.
I had a similar situation. I had a bit thought over it and reckoned it's caused by multiple backup jobs existing for the database, which means the differential backup was mislead by the wrong backup flag.
I have a production database where I run full DB backups every Sunday at 2AM and log backups every night at 3AM. The weekly full backups are around 100MB, while the log backups are around 1MB. But the log backup running immediately after the full backup (one hour after) is almost as big as the full backup (100 MB).
It's not a problem, but I'm curious as to why. Can anyone provide some insight?
Is the weekly full backup part of a maintenance plan and/or are you reorganizing/recreating indexes before the full backup? An index reorganization would explain the large logfile.
one thing to check wouldbe if the wildcard/path of the log backup is picking up some archives, or if the large backup is generating enormous log files for some reason...
Are you truncating or shrinking the log after the full backup?