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?
Related
SQL 2008 R2. Full back-up every night with replication to a 2nd server for reporting. Business critical multiple databases. SQL Log files in danger of exceeding available disk space
Shrinkfile did not seem effective. Created backup of log file and then chose GUI option to shrink log file. Having done this log file size is much more manageable. When is it safe to delete the Log file backup, or is it never?
You need to keep the transaction log backups for the full backups that you will potentially use to recover the database. E.g. if you keep the last 7 full backups, you just need to keep the log backups for the last week so you can recover the db to any point of time in the week if something is wrong.
I have SQL Server 2012, and a Backup drive apart, but it is really full. I want to move all the backups, after done, to a Network Drive. My concern is with the differential and log backups, as I don't know if they need to see the full backup to be done, or how does it works in SQL Server.
Is it safe to move the Full Backup to another drive, and then execute the daily differential backups?
Let us remember the golden rule for restoring first.
‘After restoring full database backup, restore latest differential database backup and all the transaction log backup after that to get database to current state.’
So if you have only one full backup and then keep on taking differential backup's the size of the differential backup will keep on growing everyday. In case of disaster you may have to find the older full backup and then restore the latest differential backup.
So in theory: If you take one full backup and move to somewhere else and keep on taking differential backup works.
However, there are changes that your full backup may get corrupted or your differential backup have issues. You will in that case miss another full backup.
It is always a good idea to take full backup at regular intervals. I take full backup of my databases every day when they are relatively small and every other day when they are very large.
Here is the blog post where I have written about backup timeline.
https://blog.sqlauthority.com/2009/07/14/sql-server-backup-timeline-and-understanding-of-database-restore-process-in-full-recovery-model/
To answer the question you asked, the SQL Server doesn't access the full backup itself when it makes differential and log backups. It instead keeps track of what needs to be backed up in the database itself.
The short version of that for differential backups is "the notion of what's changed (and therefore needs to be backed up) is kept track of in what are called differential change map pages" and for log backup is "the notion of what's changed (and therefore needs to be backed up) is kept track of in the transaction log itself".
The longer (and IMO more interesting) version is this excellent article by Paul Randal.
To recover, you need to restore the full backup before the differential. The normal recovery sequence is to restore the latest full backup, latest differential backup after the full backup, and log backups since the differential in sequence.
The backup files obviously need to be available in order to restore regardless of where you store them. If you were to lose the local full backup, you could not restore at all. You might consider copying the full backup to the network share as an extra layer of safety.
I have Windows scheduler calling a program that does a full database backup every day at 3:00am.
I would also like to do a transaction log backup every ten minutes.
What is the best way to sync these?
I understand that transaction logs are independent of full back-ups, but is it a problem if the two different tasks both do a backup at 3:00am? i.e. the database is asked to produce a full back-up and a transaction log back-up at exactly the same time.
Perhaps I should have one task and query SQL Server to see if the last full backup was more than 24 hours ago. If not, then do a transaction log backup.
As long as you're running SQL 2005 or higher, you can run log backups at the same time as a full backup without issue. Glossing over a bit of detail, log backups are based on the last completed full backup at the time that the log backup started. The only time it really matters is when you'd need to do a recovery and even then, it's only ever "contentious" (i.e. "which full backup should I restore given that I want to restore to this point in time?") for log backups that are taken while a full backup is in progress.
If ever you need to do a point-in-time restore for such a time, you'd work backwards. That is, first find the log backup that contains said point in time. Then, to find the full backup that it's based on, look at the database backup lsn for that log backup in either msdb.dbo.backupset or by running restore headeronly on the log backup. From there, find the full backup that has that value as the checkpoint lsn. Now, you just need to restore that full backup (using the norecovery option) and every log backup based on it up to and including the log backup you identified in the first step (again, all using norecovery). Then run restore database [yourDB] with recovery to run crash recovery and you're back in business.
I have a small SQL Server 2005 database. I take daily backup (automated) and the size of the .bak file typically comes out to be 400MB, growing by 5MB every day (which is inline with its usages).
Last night the size of the backup file jumped to 1GB. Suspecting that someone was trying to fill the database with garbage data, I ran a report (Reports -> Standard Reports -> Disk User By Top Tables) and the total size came out to be around 400MB.
Then thinking maybe something was wrong with the automated backup process, I immediately took backup again but the .bak file came out to be over 1GB. Before this automated backup yesterday, an automated task that defragments indexes also ran. However, all these months, a backup after this index optimization used to actually reduce the size of the .bak file.
I am trying to find an explanation for this big jump in size overnight and also why the .bak file is more than double the size of the the actual database disk usages?
UPDATE: I ran
DBCC SHRINKDATABASE(mydb)
to remove transaction logs. Then took a backup again. The size of the .bak file came out even bigger than last time.
This is the query I ran:
DBCC SHRINKFILE(mydb_log, 1)
BACKUP LOG mydbWITH TRUNCATE_ONLY
DBCC SHRINKFILE(mydb_log, 1)
1 - How are you backing up the data? Maintenance plans?
2 - If you are appending to the same database backup file, the backup will grow!
Check out the contents of the file.
RESTORE FILELISTONLY FROM AdventureWorksBackups WITH FILE=1;
http://technet.microsoft.com/en-us/library/ms173778.aspx
This assumes you have a dump device named AdventureWorksBackups. You can also change it to a DISK='AdventureWorks.bak'.
3 - Also, the maintenance plans do not do a good job with determining when to re-organize/update stats versus rebuild an index.
4 - Check out the ola hallengren scripts. They are way better!
http://ola.hallengren.com/
First, they create a directory structure for you.
c:\backup\<server name>\<database name>\full
c:\backup\<server name>\<database name>\diff
c:\backup\<server name>\<database name>\log
Second, each backup has a date time stamp. No appending to backup files.
Third, they clean up after themselves by passing the number of hours to keep on-line.
Fourth, they handle index fragmentation better - 5-30 = re-organize or 30+ = rebuild.
I usually set up the following for my databases.
1 - system databases - full backup every night, log backups hourly.
2 - user databases - full backup 1 x week, diff backup x 6 days, log backups hourly
Last but not least, SQL Server 2005 does not have native support for compressed backups. This does not mean you can not run a batch file to zip them up afterwards.
Third party tools like QUEST (DELL) and RED GATE used to support their own backup utility. The main reason was to fill this gap. Since SQL Server 2008, compressed backups were available. I think many of the vendors are getting rid of this utility since it is now standard.
I am a programmer, with a side job as an involuntary DBA.
I have a maintenance plan that does a full backup and a 'check database integrity' every night. I backup transaction logs every 10 minutes. The transaction log backup size spikes after the database backup - exponentially bigger. I used to rebuild indexes and statistics every night - I thought that is what was causing the transaction log spike - but removing those steps didn't change anything.
Mirroring our backups on slow connections would be helped considerably if there wasn't this massive spike - so I am hoping it is something I am doing wrong. Can anyone suggest anything?
If you are only running the log backup from 6am to midnight, then the very first log backup at 6am is backing up all the database activity that has occurred in the 6 hours since the last log backup.
This is entirely normal, and probably has nothing to do with the fact that your database backup takes place at 4am.
Since you are on SQL2008, the warning in my other answer doesn't apply, and you should be fine with running the log backups 24 hours.
Is this SQL 2000?
In SQL 2000, you're not supposed to run the log backup while the full backup is executing, or "bad things can happen", like blocking, or hugely bloated log files.
See this ServerFault post for "The Word" from "The Man", Paul Randal, who used to be in charge of the SQL engine at Microsoft.
See this follow-up post for some ideas for skipping the log backup while the full backup is executing.
In SQL 2005 or later, this restriction no longer exists, and you shouldn't have trouble running log backups and full backups at the same time.
While your full backup is running, transaction backups will not run. So how long does your full backup take? The transaction log will not be truncated during this time by transaction log backups.