I'm using SQL Server 2005.
I need to move a database to a new server with minimum downtime.
Currently my option is to take everything offline, perform a backup, copy the backup to the new server, restore the backup and bring everything back online.
The problem here is that the backup file is about 10Gb, therefore, it takes about 5-10 mins to perform this whole operation.
I've heard of people performing a full backup with everything online and then doing a differential backup so there is less to copy over.
I've taken the full backup, copied that to the new server and restored it. I've then taken a differential backup and copied it to the new server.
The problem is, when I try and restore this backup I get the message "The log or differential backup cannot be restored because no files are ready to rollforward."
I have also tried selecting both the full and differential backup but then I get the error "The volume on device 'D:\FullBackup.bak' is not part of a multiple family media set. BACKUP WITH FORMAT can be used to form a new media set."
Does anyone know what I'm doing wrong and what the easiest way of doing this is?
Thanks
It seems you did not set the NORECOVERY option on the full RESTORE.
You need this option to leave all transactions intact so that you can apply the differential backup later.
If you don't set it, the uncommited transactions get rolled back while restoring the full backup, and the last LSN of the database becomes greater than the first LSN of the differential backup.
Another quick way of doing this is to Detach the database, and then copy the underlying .mdf and .ldf files for your DB straight to the DB, then reattach. Time taken to copy a 10GB file will be much less than the Backup, and it acheives the same thing.
Related
I'm periodically getting backups of an SQL database which I would like to restore in my machine. I'm able to do that with RESTORE fullDB WITH NORECOVERY; RESTORE differentialDB WITH RECOVERY;
However, I need to access the restored database in between, as the interval in which I'm getting the backups can be a few hours.
I tried restoring full backup WITH RECOVERY, but in that case I'm getting exception while restoring differential backup.
NB: It's not just one differential backup, it's real time backups taken every few hours. I'm using C# for executing the operations.
Any help is appreciated to solve the issue. Also, let me know if I'm barking at the wrong tree.
Instead of sending SQL database backups from client as .bak files, should I opt any other way to send the data?
Take a look at the STANDBY option for the RESTORE statement. From the docs:
Specifies a standby file that allows the recovery effects to be undone.
NB - differential backups are based on the last full backup taken. So let's say that you take full backups on Sunday, differential backups every other day of the week and you're restoring every day.
Sunday, you'd restore only the full backup, bringing it online for read by specifying STANDBY with the restore
Monday through Saturday, you'd restore the latest differential backup on top of what you've already restored, again using STANDBY
When Sunday rolls around again, you'd need to restore the new full backup.
That said, you mentioned that you're on SQL Express. The database size limit is 10 Gb. At that size, how long does the restore of the full backup take? Is it worth your time? And even there, it's really "how much time are you saving the robot?" because you've already (presumably) automated the restore.
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 to create script which will create the database locally (from database which is on server). Database is 20GB+ and every day is bigger.
What is your advise to do that? I can generate script with all database objects in SSMS, but how operate with data insertion? I mean full script (script which includes data) is not good option. What about one Full Backup and Differetial Backups?
Run generated scripts for all DB objects
Restore Full Backup
Restore Differential Backup
This work is required in order to make possible to test the app locally, on my (another dev's) machine. Thank for every advise!
My advice is to go with a full backup first & get differential backups afterward.
Because a differential backup is not independent and it must be based on the latest full backup of the data. That means there should have a full backup as a base. A differential backup contains only the data that has changed since the differential base. Typically, differential backups are smaller and faster to create than the base of a full backup and also require less disk space to store backup images.
Therefore, using differential backups can save available space and also speed up the process of restoring. At restore time, the full backup is restored first, followed by the most recent differential backup.
Given the following (hypothetical) scenario, how would one best backup/restore the database.
Daily doing full backups # 12 am.
Hourly doing differentials 1 am, 2am etc
Transaction log backups on the half hours, 130am, 230am etc
I am also storing the active .ldf file on drive X and the .mdf on drive Y.
Also important the master db is on Y.
Lets say hypothetically the Y drive fails at 245am.
I have the full, diffs and transaction logs up until 230am. BUT I also have the .ldf.
In theory I would have to probably reinstall SQL Server. Then I would want to recover that database up until 245am.
I have heard of doing a tail-log backup on a restore operation BUT I don't have the .mdf anymore. So, I would need to create a new database from my full/diff/log backups. After that I'm not sure how to proceed to get that last 15 minutes of transactions.
I hope this is making sense...
Thanks!
Steve.
You are asking,how to take TailLog Backup when you don't have access to MDF files..
This works only if your database is not in BulkLoggedRecovery model or your log doesn't have Bulk logged transactions..This has been covered in depth here: Disaster recovery 101: backing up the tail of the log
Here are the steps in order
Create a dummy database with same names
Delete all files of this dummy database,by bringing it offline
Copy the original database LDF
Bring this database online which will fail..
Now you can take TailLog Backup using below command..
BACKUP LOG dummydb
TO DISK = N'D:\SQLskills\DemoBackups\DBMaint_Log_Tail.bck' WITH INIT, NO_TRUNCATE;
GO
Now since you have all the backups,you can restore to point in time of Failure
I am currently trying to backup an empty SQL Server 2008 R2 database that I designed for a project that is getting shelved for the time being. I was going through the back up procedure through the SQL Management Studio when I noticed there was an option to make a Copy Only Back Up. I looked it up to see what it was but I didn't fully understand the options I was getting.
http://technet.microsoft.com/en-us/library/ms191495.aspx
I read the entry above as well as other entries and I keep seeing the phrase "independent of the sequence of conventional SQL Server backups."
Can anyone elaborate what this statement means or more about Copy Only Backups in general? I'm not sure if it's the backup I should do in this case? (My first reaction is no)
It's a full dump of a database, where you intent to take that dump and load it into some OTHER sql server instance. e.g. It's a nice way of making a complete copy of a DB without having to take down the db, detach the db, copy the .mdf files, re-attach, etc...
Naturally, since you're not using this "backup" as an actual backup, you don't want it to interfere with your normal backup schedules, hence the copy-only functionality. It's a full backup, but will not reset the backup schedule, so your normal next incremental/snapshot backup will work as usual.
This mechanism is necessary since the built-in hotcopy/migration tools in MSSMS are basically useless and can't handle its own databases in many cases.
Normally when you take a backup, it starts (or continues, depending on the type of backup that you took) what is called a log chain. Let's say that you need a copy of your database and, for whatever reason, you can't use your normally scheduled backups for this purpose. Let's walk through the scenario where you don't use a copy_only backup
Normal full backup
A bunch of differential backups
Another full backup (to make your copy database)
More differential backups
Delete the backup from step 3 (you know... to save space)
Disaster on your actual database that necessitates restore from backup
In this case, you can only restore to the last differential backup made in step 2 because the differential backups made in step 4 depend on the full backup from step 3. Now, if the backup in step 3 were a copy_only backup, you'd be fine because you're not re-establishing a log chain (which is to say that the differential backups in step 4 depend on the full backup from step 1.
If you are creating an archive backup and continuing to back it up on the server is not a concern, then it doesn't matter whether you use it or not. It will be restorable as the database either way.