March 14, 2003 at 9:45 am
But the number of files to backups depends also of how much processor capacity you have. Because multiple backup files enable sql to backup in parallel. And be ware, because if you have multiply backyp files, and you loose one of them, the entire backup is broken. Plus, is adds more administrative issues
March 17, 2003 at 7:41 pm
hi Antares686 n racosta,
thanks for the info,
regards,
praveen
Praveen Kumar Peddi
March 19, 2003 at 3:59 pm
I finally used the old fashion way...local backup - compression - transfer. All the proccess spend 75 minutes, against the 380 used in the old method.
Thanks all for the suggestions!
March 19, 2003 at 8:27 pm
Try sqlzip. http://www.sqlzip.com
Backup local then copy across the network. Sqlzip will compress the backups on the fly instead of laying the files down and then compressing them. I have a 110gb database that only takes an hour to backup and compresses down to 10gb. The restores are extremely fast as well, 45 min to an hour to complete.
Bill Stevenson
MCSE, MCDBA
Bill Stevenson
MCSE, MCDBA
March 26, 2003 at 2:40 pm
I think its a good practice to backup to local disk first and then schedule a backup to tape later
March 26, 2003 at 2:49 pm
I have used SQLLITE Speed and am really impressed with it - don't know if we will get the nod to purchase a licence at this moment, but I think its definately worth it.
One of our larger DB's (28GB in size) normally takes around 1:40 hrs to complete a weekly backup to disk. Using SQLLITE, it took 24 mins and backup file size was around 8GB instead of 26GB.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply