March 2, 2005 at 11:55 pm
March 3, 2005 at 4:47 am
SQL Server is very unforgiving when there is any latency between it and the backup device. A single delayed packet can cause the backup to fail. That's why it's always best to backup to the local disk.
Once you have successfully backed up the file you can move it wherever you liek using something like ROBOCOPY from the Windows Resource kit.
--------------------
Colt 45 - the original point and click interface
March 3, 2005 at 4:56 am
adding to phillcart 's reply :
and implement as backupsolution Full (weekly?) / diff ? (perf.impact) / and log (hourly) backups. according to a sla.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
March 3, 2005 at 6:36 am
Consider one of the third party backup systems like SQLLitespeed (http://www.imceda.com/) or SQLZip (http://www.sqlzip.com/) which offer compression in the backup. They are very fast for local backups and the smaller size will help in copying to a remote location afterwards or even tape backups.
March 4, 2005 at 12:51 am
March 4, 2005 at 1:30 am
As mentioned above, assumming sufficient space locally, local may be preferable, as long as you ensure that you are moving this elsewhere afters, i.e. your off-site storage site, which I strongly suggest you ensure is inplace, and test ona regular basis. Remember, local storage may well go *boom* is a box goes *boom*
Given the need to move this file around, the suggestions above regards 3rd party tools to reduce the size can be VERY relevant - 250 GB takes a while to copy
Your "enterprise storage" - is this a SAN? Does it have SNAPSHOT capability? In which case you may want to consider using it, in that case.
March 4, 2005 at 2:29 am
Hi
1. It is better to place the backup files in Enterprise Storage, because you will have access from both the servers.
2. If you plan to keep backup files on hard disk, it's better to put in passive Node, Because that node will become active when the current active node goes offline.
with regards
Meenakshi
With Regards
MeenakshiSundaram Lakshmanan
March 4, 2005 at 6:26 am
Hi,
a lot depends on the overall strategy you have.
Will you do logshipping?
if yes, what is the size of the logfile(s)
What is your guaranteed recovery-time for the database?
Will one backup per day be enough or will you have to keep more than one backup on disk?
If you use somethin like SQLLitespeed, the size of your backups will be roughly a quarter of the db-size.
If you are going to copy something like that over the network, you will need a seperate networkcard just for that AND it will be a long, long, long process.
If you put everything on SAN, device a strategy to get the backupfiles on tape at a time when no SQL-Server-backup runs.
So i would advise to put the backupfiles on your SAN, but plan for a lot of space (if you have to restore, you will need at least twice the size of your db - once for the backupfiles and once for the db)
regards karl
Best regards
karl
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply