Backing up my databases locally has been in my build list for a very long time. Why? Well, primarily for manageability. I had to know that my backups were always good, and I did not want to introduce any other factors, such as network queues or interruptions. I always told myself to back them up local first, and go from there.
Today I ran into a blog that suggested it may be time to revisit this practice.
First and foremost, what are the backups for? Recovery. Aren't they? If I backup the databases locally, and my server goes down, don't I need to need to recover the hardware first, before I can get to my database .bak file(s). I am almost embarrassed to admit I have not looked at it from this perspective before.
What about moving data around production networks intraday? I don't know about you, but I have worked on some very secure AND controlled networks. In many cases, it was often frowned upon to move backup files from production to DEV/QA intraday. Not only the network, but the production resource itself! During certain hours, these machines are locked down. It would be much easier to access last night's backup, if it was written to a network share, rather than the production server.
There are a few other reasons, but I believe these two are the most pointed, obvious reasons to consider writing your backups to a network share, rather than the local disk.
No comments:
Post a Comment