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:
- RPOs and RTOs: Obviously, if you’ve got RPOs and RTOs in the sub 1-minute range for DATA CENTER failures (as opposed to ‘mere’ server crashes/etc), then any typical ‘consumer level’ online backup scheme usually won’t work for you. Whereas if your business is ‘comfortable’ with the idea that loss of entire servers or data-centers might result in a few hours of down time and/or data-loss, then online backups make sense. In either case, Dropbox (or any other online backup service) is NOT a substitute for full-blown backups on site. Instead it’s merely an option for redundancy – in cases where the idea of having SOME kind of failover or backup options after the loss of a data center makes sense.
- Throughput. The reason I’m specifying Dropbox as an option in this post is simple: it’s the ONLY consumer-level off-site backup solution that I’ve seen that’s been able to keep up with the need to keep roughly 100GB worth of backups synchronized in MORE OR LESS real-time. (Full backups, of course, obviously are always going to take a bit of time to get pushed up to Amazon’s/Dropbox’s servers). But, it should go without saying that IF you’re looking for off-site backup redundancy, you’re going to need decent upstream if you’ve got any sizeable amount of data that you’re looking to backup. Along those lines, if you’re pushing gobs and gobs of data around, then consumer-level services likely won’t be a win and you’re potentially ‘enterprise-y’ enough that you’ll need some sort of dedicated fiber to an off-site location ANYHOW.
- Security / Sensitivity. Any time you’re dealing with sensitive or secure data you obviously need to keep tabs on your backups. Consequently, if you’re uploading copies of your backups to a non-secured third-party storage location you’ll want to way the risks/benefits accordingly. That said, a great and OBVIOUS solution here is that IF you’ve got sensitive data you should be encrypting your backups ANYHOW. And if that’s done correctly/initially that CAN mitigate the potential concern associated with storing your data off-site. (i.e., this concern is bigger than merely a question of worrying about Dropbox.)
- Dropbox’s Execution Model. As much as I absolutely love Dropbox it suffers from one pretty decent limitation – which is that it is NOT designed to run in any sort of unattended fashion. Or, in other words, Dropbox (as installed typically) spins UP when you log in, and then runs as long as you stayed logged in. That obviously presents some decent problems for unattended execution on servers. For example, not only does that mean that if you get everything synchronized on your server and then ‘disconnect’ or log out that you’ll have problems, but (even more importantly) if the server reboots and you haven’t logged in, you’ll potentially run for ‘days’ without any synchronization – thereby completely negating the use of Dropbox as a means of synchronizing your backups off line. Happily, though, there’s a pretty easy fix to this problem.
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:
- Installing Dropbox as a Service on Windows Server 2003, 2008 (x64)
- Installing Dropbox as a Service on Windows Server 2008 R2 SP1 (x64)
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.
