we have a huge (17 gig) MSDE backup file that have discovered has been appending nightly for the last 4 years.
We had a database failure last night and now we need to restore the database.
We tried a standard restore but it restored the database info all the way back to 2008. Which isnt an accurate reflection of the state of the database as it was last backed up.
How do we restore back to just the last backup (or even a date/time) and not all the way back to 2008?
cheers
Buzz
openthe log file, findout the date of the backup you want then use the script
RESTORE DATABASE [restoretest] FROM DISK = N'C:\folder\backfile.bak' WITH FILE = 1494
GO
hurray a working answer.
Buzz
Related
I'm having a bit of trouble understanding the purpose of the WITH FORMAT option of the SQL Server BACKUP DATABASE command.
Using the MSDN example:
USE AdventureWorks2012;
GO
BACKUP DATABASE AdventureWorks2012
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012.Bak'
WITH FORMAT,
MEDIANAME = 'Z_SQLServerBackups',
NAME = 'Full Backup of AdventureWorks2012';
GO
I understand this deletes any existing backups and creates a new one.
If I was to omit the WITH FORMAT line, and I already had a backup at Z:\SQLServerBackups\AdventureWorks2012.Bak, what does this mean to my backup?
Is it incremental or does it overwrite with a full one?
It's a full backup, essentially appended to the file if it exists already, you'll see a File number 2 reference when you run it, and you'll see the backup file double in size. Each backup is independent of each other and either can be restored.
I've created a Back Up Database Task for a few selected databases in my server. What I want to do is to have only one backup file for any database. The new one could overwrite the old one or create a new one and delete the old one, doesn't matter. I've checked Backup set will expire: 2 days but but evidently this doesn't do what I thought it'd do, it keeps creating new backup files every day. How can accomplish this?
I wouldn’t set the backup to expire in 2 days, as this means that you can only restore the backup for two days once the backup expires you can no longer rebuild the database using it.
In the same why you built a maintenance plan to backup the database you can create a maintenance plan to clean up the system and delete backup over x days old. then just run it after your backup plan.
Use a history cleanup task and then pick, remove everything older than 1 day or whatever your desired time frame is
I am running SQL Server 2005.
My db backup scheme is:
Recovery model: FULL
Backup Type: Full
Backup component: Database
Backup set will expire: after 0 days
Overwrite media: Back up to the existing media set, Append to the existing backup set
The db is writing to 250GB drive (232GB actual).
My _Data.mdf file is over 55GB and my _Log.ldf is over 148GB.
We ran into a situation where our drive was filled today. I moved our ab_Full.bak and ab_Log.bak files to another drive to make space - about 45GB. Five hours later, free space is at 37GB.
I'm new to managing SQL server; so, I have some basic questions about my backups.
I know I need to update the db to start managing the transaction log size to help prevent this problem in the future. So, assuming I have enough free space, I:
1. right click the db and choose Backup
2. set 'Backup Type' to 'Transaction Log'
3. change 'Backup set will expire' after to 30 days
4. click 'ok'
My understanding is this will move 'closed' transactions from the transaction log to a backup and truncate the transaction log.
Is this plan sound? Will I need to manually resize the log file afterwards?
Thanks for your time.
Are you backing up the transaction log at any time at all?
If you are using the FULL recovery model, then you need to back up the transaction log in addition to backing up the main database, or if you don't want to back up the log (why would you then use the FULL recovery model?) then at least truncate the log at some regular interval.
You should back up the transaction log before every full backup (and keep it as long as you keep the previous full backup) so you can restore to any point in time since the first full backup you've kept. Also, it might be worth backing up the transaction log more often (the total size is the same) in case something bad happens between two full backups.
The best procedure is to regularly backup your log file. In the mean-time, for 'catastrofic' scenarios like the one you described, you may use this snippet to reduce the size of your log:
http://www.snip2code.com/Snippet/12913/How-to-correctly-Shrink-Log-File-for-SQL
I am using SQL Express 2005 and do a backup of all DB's every night. I noticed one DB getting larger and larger. I looked at the DB and cannot see why its getting so big! I was wondering if its something to do with the log file?
Looking for tips on how to find out why its getting so big when its not got that much data in it - Also how to optimise / reduce the size?
Several things to check:
is your database in "Simple" recovery mode? If so, it'll produce a lot less transaction log entries, and the backup will be smaller. Recommended for development - but not for production
if it's in "FULL" recovery mode - do you do regular transaction log backups? That should limit the growth of the transaction log and thus reduce the overall backup size
have you run a DBCC SHRINKDATABASE(yourdatabasename) on it lately? That may help
do you have any log / logging tables in your database that are just filling up over time? Can you remove some of those entries?
You can find the database's recovery model by going to the Object Explorer, right click on your database, select "Properties", and then select the "Options" tab on the dialog:
Marc
If it is the backup that keeps growing and growing, I had the same problem. It is not a 'problem' of course, this is happening by design - you are just making a backup 'set' that will simply expand until all available space is taken.
To avoid this, you've got to change the overwrite options. In the SQL management studio, right-click your DB, TASKS - BACKUP, then in the window for the backup you'll see it defaults to the 'General' page. Change this to 'Options' and you'll get a different set of choices.
The default option at the top is 'Append to the existing media set'. This is what makes your backup increase in size indefinitely. Change this to 'Overwrite all existing backup sets' and the backup will always be only as big as one entire backup, the latest one.
(If you have a SQL script doing this, turn 'NOINIT' to 'INIT')
CAUTION: This means the backup will only be the latest changes - if you made a mistake three days ago but you only have last night's backup, you're stuffed. Only use this method if you have a backup regime that copies your .bak file daily to another location, so you can go back to any one of those files from previous days.
It sounds like you are running with the FULL recovery model and the Transaction Log is growing continuously as the result of no Transaction Log backups being taken.
In order to rectify this you need to:
Take a transaction log backup. (See: BACKUP(TRANSACT-SQL) )
Shrink the transaction log file down
to an appropriate size for your needs. (See:How to use DBCC SHRINKFILE.......)
Schedule regular transaction log
backups according to data recovery
requirements.
I suggest reading the following Microsoft reference in order to ensure that you are managing your database environment appropriately.
Recovery Models and Transaction Log Management
Further Reading: How to stop the transaction log of a SQL Server database from growing unexpectedly
One tip for keeping databases small would be at design time, use the smallest data type that you can use.
for Example you may have a status table, do you really need the index to be an int, when a smallint or tinyint will do?
Darknight
as you do a daily FULL backup for your Database , ofcourse it will get so big with time .
so you have to put a plan for your self . as this
1st day: FULL
/ 2nd day: DIFFERENTIAL
/ 3rd day: DIFFERENTIAL
/ 4th day: DIFFERENTIAL
/ 5th day: DIFFERENTIAL
and then start over .
and when you restore your database , if you want to restore the FULL you can do it easily , but when you need to restore the DIFF version , you backup the first FULL before it with " NO-recovery " then the DIFF you need , and then you will have your data back safely .
7zip your backup file for archiving. I recently backed up a database to a 178MB .bak file. After archiving it to a .7z file is was only 16MB.
http://www.7-zip.org/
If you need an archive tool that works with larger files sizes more efficiently and faster than 7zip does, I'd recommend taking a look at LZ4 archiving. I have used it for archiving file backups for years with no issues:
http://lz4.github.io/lz4/
I have been using this query:
BACKUP DATABASE RentalEase
TO DISK = 'C:\RentalEaseBackup\RentalEase.bak'
WITH COPY_ONLY;
GO
To backup my database. Someone deleted something so now I have to restore it from a previous point in time, however I don't want to overwrite new changes (other than the deletions).
What I was thinking I could do it attached the backup to the SQL Server as a new database and then perform the necessary queries to move the few deleted rows over. However, it won't attach the RentalEase.bak file because it says it isn't a primary database file.
How can I attach the database backup so I can run the SQL queries against it?
You have to RESTORE the DB, you can't attach a backup file
RESTORE DATABASE TestDB
FROM DISK = 'c:\Northwind.bak'
WITH MOVE 'Northwind' TO 'c:\test\testdb.mdf',
MOVE 'Northwind_log' TO 'c:\test\testdb.ldf'
Full syntax here
Restore the database to a different database name, and then you can do whatever you want between the two databases (good luck!)
create a new database named RentalEase2, A restore would look like this
RESTORE DATABASE [RentalEase2] FROM DISK = N'C:\RentalEaseBackup\RentalEase.bak'
WITH FILE = 1, NOUNLOAD, STATS = 10
GO