May 14, 2010 at 9:21 am
All kidding aside, log shipping is going to be your easiest and cheapest route to go. Set it up a week or two in advance. Then when you are ready to do the switch, turn off your production box, restore the latest transaction log and point your app server to the location. Should take less than 20-30 minutes at most. Unless I am missing something, this is a no-brainer. The only complication would be if your network wont support shipping the log's before hand. But unless you have huge logs or your network is really that bad :), you should be fine.
May 14, 2010 at 1:41 pm
Amazon CloudBerry Backup strategy seems to be one of the considerable solution for this situation.
More details on this article at
May 17, 2010 at 9:15 am
Thanks to everyone for your replies and suggestions. It looks like we're going to get a temporary bandwidth increase for this so I'll probably just do the backup/copy/restore. We use RedGate with max compression so I think that is the quickest solutions with the least risk. I like the log shipping solution but I don't know if our current bandwidth would support the initial ship...
Thanks again,
Brett
May 17, 2010 at 10:13 am
If the full backup is too large to get over the network, send that overnight in a package on tape or USB disk, and then send the transaction log backups over the network and roll them forward after you restore the full backup.
It sounds like you have a fairly small amount of data to move. If you can move an 8 GB backup in 2 hours, you should be able to move them all in less than 24 hours and then roll the transaction logs forward after that.
I would setup ROBOCOPY in SQL Server jobs to mirror the full backup directories, and separate jobs to mirror the transaction log directories to the new location. Be sure to use the /Z option for re-startable copies and the /R option to automatically retry failed copies.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply