Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 Import/Export (DTS) and Replication (2000)
 Ouch... big mistake with DTS!

Author  Topic 

lkevinl
Starting Member

4 Posts

Posted - 2007-01-03 : 09:36:13
OK, I made a big mistake. I'm using SQL Server 2000, latest SPs (not the mistake!).

I currently back up my client's database with a backup job each night at 2am.

In addtion, I use a DTS package to copy the database to my development machine at my office. The DTS is run as a job each night at 11pm, so it happens BEFORE the backup job. I recently got a new development machine and so, in Enterprise Manager, I registered my clients server, the server on my old development box and the new server installed on the new development box. I then tried to to create the DTS job on the new box to pull the database from my client's server to the new box.

INSTEAD, in Enterprise Manager, I was creating the job on the clients box, not on the new dev box, so when I specified source, I used the IP address of the client box, and destination I used (local) and created the job ON THE CLIENT BOX! So, at 11pm, the job tried to import onto itself. The result: all tables empty. I lost 1 days worth of data since the job ran at 11pm before the backup job that runs at 2am.

This was idiotic on my part. My client has to reconstruct his data. Is there anyway I could roll this back?

JoeNak
Constraint Violating Yak Guru

292 Posts

Posted - 2007-01-03 : 09:45:17
If your database is in Full Recovery mode and you're backing up the transaction log, you can do a point in time restore.
Go to Top of Page

JoeNak
Constraint Violating Yak Guru

292 Posts

Posted - 2007-01-03 : 09:47:08
In addition I'd think about backing up prior to copying the database or copy the backup file and restore that.
Go to Top of Page

lkevinl
Starting Member

4 Posts

Posted - 2007-01-03 : 14:12:52
It's not in full recovery mode unfortunately.
I'm unfamiliar with how that works. Do I just enable Full Recovery mode and the transaction log gets backed up automatically or do I enable full recovery and then schedule regular transaction log backups?

Then, let's say a problem like this does happen, what are the steps to recover? I assume you restore the database backup from the previous night but how do you apply the transactions via the transaction log?
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2007-01-03 : 14:44:16
quote:
Originally posted by lkevinl

It's not in full recovery mode unfortunately.
I'm unfamiliar with how that works. Do I just enable Full Recovery mode and the transaction log gets backed up automatically or do I enable full recovery and then schedule regular transaction log backups?

Then, let's say a problem like this does happen, what are the steps to recover? I assume you restore the database backup from the previous night but how do you apply the transactions via the transaction log?



First, restore the database from the full backup with the NORECOVERY option.

Then use the RESTORE LOG to restore each log backup in order from oldest to newest. Use the NORECOVERY option on each one, except for the last one.



You're lucky you still have that client. You need to be extra careful when you don't know what you are doing. The rule to go by is: "First, do no harm" And always, always, always have good backups.









CODO ERGO SUM
Go to Top of Page

lkevinl
Starting Member

4 Posts

Posted - 2007-01-03 : 14:58:21
Lucky indeed! It's my brother-in-law's business, so likely wouldn't lose the client be Thanksgiving could become a bit tense!

So to do what you describe, what recovery mode would I need to use?
If full recovery mode is required, how do I prevent the transaction log from getting too big?
Are there any other steps required like setting up transaction log backup jobs?
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2007-01-03 : 15:08:10
Set the database to full recovery mode, schedule a full backup job to run once per day, and run that job. Then setup a transaction backup job to run at least every 15 minutes 24x7, more often if the log grows too large. Set the job to retain the transaction log backups at least 3 days. Retain the full backups for a few days if you have enough disk space. Make sure you also get at least a daily backup of the system databases; they should not be set to full recovery.

That is just to get you started. You also should look at some kind of automatic tape backup so that you are covered when you don't discover that "oops" for a few days.



And never do business with relatives or friends.










CODO ERGO SUM
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2007-01-03 : 16:21:43
In case it helps: http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55210&SearchTerms=How%20Backup%20works,What%20type%20of%20backup%20should%20I%20use,Automating%20Backups,Backup

Kristen
Go to Top of Page

lkevinl
Starting Member

4 Posts

Posted - 2007-01-03 : 16:25:21
Hi Michael, thanks much! That was exactly what I'm looking for.

I'll test this on my dev box.

When I do a restore if the daily back-up at one stage do the transaction log back-ups get applied, during the restore or as an addition step(s)? For instance, to recover to a certain point in time, I'd first restore from the daily back-up and then what?

The final production box for their app. will have RAID 1 and USB drive back-ups, neither of which would have helped with this situation, human error. I can out-smart most failsafe counter measures.
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2007-01-03 : 16:33:58
See http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55210&SearchTerms=RESTORE%20syntax%20/%20example

Basically:

Restore a FULL backup

Restore a DIFFERENTIAL backup (taken at some time after the Full backup, and based on it. This is optional) - a differential backup can reduce the number of TLog backups that then have to be restored - e.g. if a Full backup is taken once a week and TLog backups every 10 minutes a system failure 6 days and 23 hours later is a lot of Tlog backups to restore : (6 * 24 + 23) * 6 in fact!in such a situation taking a Diff backup daily means that only 1 diff + (23 * 6) tlog backups have to be additionally restored.

Restore ALL Transaction Backups thereafter, in order, up to the last one that is required.

For the last one optionally specify a Date/Time when the restore should stop - otherwise the whole of the last transaction backup will be restored.

SQL Server will give you an error if you restore the TLog backups out-of-order, but the error is not fatal - you can locate the correct TLog backup and continue restoring with that and so on until you are done.

Kristen
Go to Top of Page
   

- Advertisement -