Delay's Blog is the blog of David Anson, a Microsoft developer who works with C#, XAML, HTML, and Azure.
I've seen a few references to backup strategies on blogs and discussion
lists lately and thought I'd write a bit about the strategy I recently decided on and implemented. Of course, everyone
has their own
approach to file management, their own comfort
level for security, and their own ideas about
what's "best". That's life and I'm not going to try to persuade anyone that my way is better than their way - but I will outline my way in case it's useful for others, too. :)
The setup: My machine is running Windows 2003 Server and I try to
keep as much unnecessary stuff off it as possible (no games, no P2P programs, no weird drivers, etc.). Along the
same lines, all user accounts on the server are
members of the restricted access
Users group, not the Administrators group. The machine has one hard drive
for storing the operating system and all programs (60 GB) and another hard drive
for storing all data (320 GB). The data drive has a Mirror directory
under which all data to be backed up is stored. The Mirror directory is ACLed to allow the
Users group read/write access. Non-private subdirectories of it are shared out for read-only
access by Users. I have an external USB 2.0 drive enclosure for backing up to (200
GB) that is normally powered off and that I mirror the Mirror directory to every
couple of days or so. The external drive
is ACLed to allow only members of the Backup Operators group to make changes. My data consists of the usual personal stuff (email, source
code, etc.), all digital photos I've ever taken, all digital video I've ever taken,
sentimental stuff (like wedding videos, baby's ultrasound video, etc.), and some
of my music collection in WMA Lossless format. Very little data changes day-to-day, so
a simple tool like RoboCopy (free with the Windows 2003 Resource Kit) is more than
enough to keep the backup directory in sync (use RoboCopy's /MIR switch to
make this easy). Along with the rest
of the data is a file that records the MD5 hash of every file in the backup. As my data storage
needs increase (which they do each time I take a picture or shoot a video!), I'll eventually
buy a new large hard drive and swap it for the smallest of the two data drives currently in use.
As long as my storage needs don't grow too rapidly, I'm figuring
the cost of
upgrading to be about $100 each year (that's the cost of a mid-sized drive like the 320 GB
I purchased a few months ago). I'm counting on storage capacity to continue increasing like it
has so that I'll always be able to buy $100 drives when I need to increase
the storage space.
Benefits provided by this approach:
Problems this approach does not solve:
I think this overview touches on pretty much all of the key points of this strategy.
It's obviously not a perfect solution, but it meets most of my requirements
and I'm pretty happy with how it's been working out so far. However, I'm always
open to improvements - if you have any suggestions, I'd love to hear them!
As you may already know, we released the "Atlas" Control Toolkit a few weeks ago to almost universally positive feedback.
But it's hard to please everyone, and we got some negative feedback on our relative lack of support for Apple's Safari web browser. (Opera was mentioned, too, but it's another story that I may blog about some other day.) Contrary to the article's suggestion, we actively developed and tested our code on both IE 6 and Firefox 1.5; all nine controls worked in both browsers with two very minor exceptions due to specific limitations. However, we didn't have the time or resources to test with Safari, so our results for that browser were not very good. Sorry about that!
This time around, Safari support was a BIG priority. In fact, we probably spent more time with Safari than with IE or Firefox! Safari brings with it a number of peculiarities and unfortunately has not yet been a specific focus of the Atlas team (like us, they hadn't gotten around to implementing complete Safari support). So we started out at somewhat of a disadvantage. But a whole bunch of dedicated effort - and a variety of elegant (and some less-than-ideally-elegant) workarounds - have gotten us to the point where all but two of our controls work great on Safari! That's a pretty significant improvement for only three week's time during which we also fixed bugs, added new features, helped users on the "Atlas" Control Toolkit Forums, incorporated a bunch of their feedback, and added new documentation.
Oh, yeah, we also added *four* new controls to the Toolkit!! (Which all work flawlessly under Safari, by the way.) I'm happy to introduce the...
The release notes for the latest version outline a bunch of other improvements we made in the past three weeks. Please take a minute or two to read about all the new stuff. And while you're at it, sample the new (and existing) controls on the web right now (no install required). Then go ahead and download the new Toolkit so you can start creating your own controls!
As always, if you have any feedback, please share it with us on the forum (or email me)!!
Next up: Enabling community submissions to the Toolkit... (Yum, it's going to be good!)