Using Dropbox for SQL Server Backups

It should go without saying that organizations aren’t created equally; what works for some would be preposterous for others, and so on.

Related: SQL Server Backup Comparison

With that huge caveat out of the way, I’ve got a few smaller business (and even a couple ‘medium’ business) clients who need some sort of ‘smoke and rubble’ contingency plan for their data – that doesn’t require dark-fiber, enterprisey-level SAN replication, or other types of redundancy that trend into the hundreds of thousands of dollars for licensing and throughput. For a couple of these clients, Dropbox has actually served VERY well as a way to achieve backup redundancy.

Limitations

When it comes to using ANY online/cloud backup for redundancy, there are a couple of limitations – some obvious, others not so obvious:

Configuring Dropbox to Run as a Service

I’ve found two great tutorials that outline, in step-by-step and idiot-proof fashion how to set up Dropbox as a service. And, in using this approach across a couple of different servers for a couple of different clients (as well as in my own environment), I’ve developed excellent faith in Dropbox’s ability to run ‘unattended’ – or as a service.

To do this, I just create a ‘DropboxAsService’ folder in the C:Program Files folder on the servers where I want Dropbox to run unattended, then walk through the requisite step by step instructions for whichever server OS I’m dealing with:

The ONLY rub I’ve found with either of those excellent tutorials listed is that for 2003/2008 you’ll need two .exes from the Windows Server Resource Kit, while you’ll only need one .exe for Windows Server 2008 R2. (And, as much as I would have loved to just link to those .exes (which are 22KB when zipped), I’m pretty sure Microsoft doesn’t want me redistributing their IP or those particular files – so to make this work you WILL need to grab those files yourself.)

Otherwise, the only other thing that (should go without saying) is that IF you chose to run Dropbox ‘as a service’ you’ll LOSE the awesome Dropbox GUI. Typically that’s NOT an issue. It is, however, a bit of a problem or concern IF you want to get a feel for where Dropbox is in terms of synchronization (because you won’t be able to just look in the sys-tray at synchronization status). That said, I HAVE occasionally ‘cheated’ and spun up/started the ‘normal’ Dropbox GUI in a few cases just to ‘check’ on sync status when pushing huge files and it seems that Dropbox doesn’t apparently care TOO much if you’ve got two or more instances of the Dropbox.exe running simultaneously. Still, even in cases like this, I open up the ‘GUI’ version, peek in after it’s had a few seconds to figure out what’s up with Sync status, and then terminate the ‘GUI’ version.

Along those lines – and out of paranoia/worry of somehow letting two or more instances of Dropbox.exe fight each other to the death on a server where Dropbox is configured to run as a service, I take the following approach when setting up Dropbox as a service on servers. First, I remove all shortcuts to the the Dropbox ‘GUI’ launcher or application. Then, I navigate out to the Dropbox site in a browser, then drag a shortcut to that on the desktop – as a replacement for ‘seeing’ what’s up with Dropbox.

Otherwise, I’ve actually met with enough success in terms of Dropbox being able to ‘keep up’ with backups well enough for smaller-ish databases and deployments that I’ve ACTUALLY been able to 100% use it for a log shipping topology allowing two AWS EC2 instances in different data centers to keep a luke-warm backup running on standby (with a very small-ish database). Or, in other words, if you’re a small to medium business and don’t have any sort of smoke and rubble contingencies on hand, Dropbox CAN be a viable option to get started with.