July 28, 2011 at 1:03 am
My primary database in logshipping is more than 500 GB.I need to restore the database on secondary server.
Sites are quite far and also not the eligible WAN link for such big copy paste.
Is there any possibilty that without going to secondary site I can restore the DB.
Thanks
July 28, 2011 at 1:41 am
forsqlserver (7/28/2011)
My primary database in logshipping is more than 500 GB.I need to restore the database on secondary server.Sites are quite far and also not the eligible WAN link for such big copy paste.
Is there any possibilty that without going to secondary site I can restore the DB.
The backup must reach the secondary location. Either by copying or by sending the backup in an external drive or tape by courier.
BTW, what is the version of SQL Server you are using?
July 28, 2011 at 1:53 am
I would not rely on Window copy for anything that size across a potentially unreliable WAN connection. You need something with the capability of restarts after network errors. So something like FTP or Robocopy.
You could try compressing the backup (either with SQl server backup compression, or a zip utility) to reduce the size transmitted.
I would then do some test copies of say a 1GB file and then simple maths to work out how long it will take to copy, you may well find a USB drive and motorcycle the quickest and cheapest.
Good luck
Mike
July 28, 2011 at 1:55 am
Chandan:
Are you sure about this?r u sure?
Thanks
July 28, 2011 at 2:26 am
forsqlserver (7/28/2011)
Chandan:Are you sure about this?r u sure?
Yes I am sure. I asked you about sql version because SQL 2008 R2 standard and enterprise versions have a capability to compress backups. And I am 90 percent sure that you are on one of these as I have been responding to your questions off late and can recall it.
Try compressing the backups and apart from it, split the backups into multiple files and then try copying one small file to find how long it takes for 1 GB file or so.
If this is still unreliable, then sending the backup through courier is a great option. Once it is sent and copied over the disc there, you can restore it with no recovery and then copying transaction logs should be a bit easier. Make sure that when you are planning to copy transaction logs, you do not run an index jobs as they lead to huge growth on T-log files.
July 28, 2011 at 3:55 am
Ignacio A. Salom Rangel (7/28/2011)
Mike's tip is very good. In case you don't have SQL 2008 Enterprise of SQL 2008 R2, you can still compress the backup.
In 2008 R2, even standard edition can compress the backups. This is the reason I asked the user to try using SQL backup.
July 28, 2011 at 4:04 am
chandan_jha18 (7/28/2011)
Ignacio A. Salom Rangel (7/28/2011)
Mike's tip is very good. In case you don't have SQL 2008 Enterprise of SQL 2008 R2, you can still compress the backup.In 2008 R2, even standard edition can compress the backups. This is the reason I asked the user to try using SQL backup.
that is why I said "SQL 2008 Enterprise or SQL 2008 R2", I did not mentioned anything about the version of SQL 2008 R2.
July 28, 2011 at 4:09 am
Two more options come when for full backup restoration when we do the secondary database settings...
I am using standard edition.
Thanks
July 28, 2011 at 4:12 am
Sorry but I am not sure what you are asking here, what specific options are you referring to?
Mike
July 28, 2011 at 4:15 am
Ignacio A. Salom Rangel (7/28/2011)
chandan_jha18 (7/28/2011)
Ignacio A. Salom Rangel (7/28/2011)
Mike's tip is very good. In case you don't have SQL 2008 Enterprise of SQL 2008 R2, you can still compress the backup.In 2008 R2, even standard edition can compress the backups. This is the reason I asked the user to try using SQL backup.
that is why I said "SQL 2008 Enterprise or SQL 2008 R2", I did not mentioned anything about the version of SQL 2008 R2.
I did not understand what you wanted to say here.Can you please explain.
Also, since you are fairly new to all this, I suggest that if you are trying something on a production server, get help from some expert in person or try to find someone in your social circle. I really do not suggest you to try anything on production.
July 28, 2011 at 4:16 am
I guess the best way to do this would be to copy the backup on a disk and send the disk to the secondary location.
Mainly coz its simpler and easier to do. Transferring the backups over the network on a bad WAN is not bullet proof.
Heres another post with a similar issue
http://www.sqlservercentral.com/Forums/Topic1080281-357-1.aspx
July 28, 2011 at 4:27 am
Mike :
The options are:
1. Yes generate a full backup of the primary database and restore it into the secondary database ...
2. Yes restore an existing backup of the primary database....
Thanks
July 28, 2011 at 5:19 am
chandan_jha18 (7/28/2011)
Ignacio A. Salom Rangel (7/28/2011)
chandan_jha18 (7/28/2011)
Ignacio A. Salom Rangel (7/28/2011)
Mike's tip is very good. In case you don't have SQL 2008 Enterprise of SQL 2008 R2, you can still compress the backup.In 2008 R2, even standard edition can compress the backups. This is the reason I asked the user to try using SQL backup.
that is why I said "SQL 2008 Enterprise or SQL 2008 R2", I did not mentioned anything about the version of SQL 2008 R2.
I did not understand what you wanted to say here.Can you please explain.
Chandan, as you mentioned SQL 2008 R2 supports backup compression on the standard, enterprise and datacenter edition, but 2008 does not supported on the standard edition, that is why I did not mention which version of SQL Server 2008 R2 could be use for backup compression. I hope it is clear to you now. 😉
Also, since you are fairly new to all this, I suggest that if you are trying something on a production server, get help from some expert in person or try to find someone in your social circle. I really do not suggest you to try anything on production
Did you direct that comment to me?
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply