Improving back-up, performance and audit strategy
-
I am a new dba in a start up company with very limited resources. Currently the backups run nightly on a set of servers stored off-site. The company is still utilizing its original isp provider for it's primary internet service solution. There is no T1, no domain/active directory structure set on the "external" public side of the network. The "internal" or intranet side is housed over a WAN2 Miniport wireless network and the 5 databases it touches are configured by one person at the offsite location. To make a long story short, there are bandwidth issues which prevent more traditional warehousing or replication solutions from being implemented. Currently we have jobs set up nightly that put the differential, data and transaction logs out on a separate network share not accessible from our "internal"/corporate net. The sys admin then physically removes the 250 G hard drive and brings it with him to the corporate office where it is installed in a staging server accessible to app developers for testing purposes. In the week and a half I have been here I have seen instances where data is corrupted, or where tables are accidentally deleted and can not be restored until the next day. The business is growing and will one day have the resources to re-architect, but at this point in time finances are limited. Is there anything I can do to improve the backup and maintenance process in this situation...short term?
I need all the help I can get.
Regards,
Anne
Anne -
Hmmm... does this 250gb hard drive contain a backup that ius the n restored or are these attached files or what? I think its weird that the data is corrupting from a backup like that .
-
I don't know why it does it...and it's not consistent, either. I just know that there were a few instances of data being corrupt after the restore, but that it's not always the case.. To be more specific, in regards to the process. The full backup is done on Saurdays, and then differential backups are scheduled every 4 hours to account for updates and inserts and any new transactions, as the case may be. I believe (but don't quote me on it) that the app developers hard code database calls into their applications and this causes the transactional log to dump to the same location where differential backups go on a regular basis, but I haven't been here long enough to investigate this feature.. the guys doing the backups then run into the issue of having to delete transaction logs to conserve already limited server resources and who knows... maybe some differentials got thrown out too. It's like the baby and the bathwater
...no seriously, this is a raised flag that I intend to address as part of the re-architecture solution.. suggestions are welcome, of course.Anne
Anne
...no seriously, this is a raised flag that I intend to address as part of the re-architecture solution.. suggestions are welcome, of course.Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply