Monthly Archives: May 2008

Why I switched from Mozy to Carbonite

I’ve been using Mozy for my personal backup solution for nearly a year and a half. It is a great service that basically relieved me from ever worrying about my backups. It is a great service, but lately it has really gone down hill.

Starting about six months ago, I started having trouble where Mozy would just fail to backup for several days at a time. I’d get a message that it had been 3 or more days since the last successful backup. I’d have to manually start a bac kup several times before it would actually upload some files. After contacting Mozy support, it appeared that their latest auto-update had failed and my configuration and whatnot was corrupt. After a total uninstall, reinstall, and complete re-upload of all my data, things went back to normal for awhile.

Recently, I’ve been having a new problem. Whenever I would use Windows explorer, and would try to cut/copy/paste files around my hard drive, explorer.exe would crash. One day, while cleaning out files, I had at least 20 crashes in an hour. When I dug deeper I found the crash to be caused by mozy.dll. This time, a complete uninstall/reinstall didn’t fix the problem.

The straw that broke the camel’s back is when I opened the mozy status app and discovered that my backups were almost a month behind! And I wasn’t even getting notified that my backups had failed! Obviously, this is no longer worry free.

Switching to SugarSync
I happened to get my hands on an invite to SugarSync, so I decided to give that a try. It sounded like it would the answer to all my needs. Not only would it automatically backup all my files, but I could also sync between several computers (a function previously filled by FolderShare). Unfortunately, after trying it out for a few days I discovered two major issues:

  1. Files would fail to upload / sync regularly. I’d have to wait days for a file that I created on my desktop to show up on my laptop. That doesn’t bode well for the backups either.
  2. Many files would have issues with read locks. I’d constantly get error messages from files that were being updated but were still open (specifically: Quickbooks files & KeePass files). Both programs create temp lock files and keep the databases locked open while in use. SugarSync just couldn’t handle this and I was extremely worried about data corruption.

Switching to Carbonite
After about two months of these issues, I decided to try Carbonite. I switched my syncing back to Foldershare and installed the client. So far it has been terrific. I’ve got a laundry list of great pros:

  1. It has no problem handling locked open files
  2. It’s fast (uploads much faster than Mozy or SugarSync)
  3. It uploads changed files almost instantly (it doesn’t even seem to wait until night-time or anything)
  4. It has explorer integration to quickly decide what to backup (Mozy has integration for restoring, but backup/status)
  5. Best of all: It adds little dots to backed up folders in explorer. Yellow dots: files not yet backed up. Green dots: Everything a-ok.

The price is comparable to Mozy and I think will be worth every cent. Here’s to Carbonite!



Bookmark and Share

How to scale Rails

So we established previously that Rails really can scale!  Now it’s time to look at how to do it.  I’ll list here the basic steps and then follow up with a post on each of these:

  1. Of course, Memcached helps a ton!
  2. Start with a master database and add two or three slave databases.  Split your reads from your writes. Rails has a great plugin for this that makes it about as easy as it can be (certainly easier than PHP). This will move you to being able to handle 15 or so app servers.
  3. Denormalize some of your data to reduce query intensity.
  4. Shard your data. Put statistics/usage data on a totally separate set of DB boxes from your user’s data.  If you really are the next MySpace,  check out AsterData for offloading some of that work.
  5. Switch to a commercial DB setup. If you’re still desperate to expand, then a more robust DB is probably in order. The great part: Rails is database agnostic (at least far more so than PHP or ASP) and will happily switch without too much effort.

Deploying Rails Applications by Ez

I
recently received Ezra’s new book "Deploying Rails Applications" in
the mail.  It is a terrific reference and I will be following up shortly with an in-depth review.

I was quite delighted to find that I had already done even the most advanced tasks regarding scaling at
least once or twice (e.g. load balanced app servers, clustered MySQL,
Memcached, CDN for static files, & extensive
benchmarking/profiling/optimization).

Rails lets you write really bad SQL

So last post, we established that Rails’ Achilles heel is in scaling the DB. PHP, Perl, ASP, etc. all rely on a database behind the scenes, and all need to scale their DB alongside the rest of the application. Rails often gets the bad rap though.
Why? I can think of only one reason:
Rails lets you write REALLY bad SQL very easily
Which means we wind up with Rails applications that are dying a slow DB
death much sooner than their counterparts that use a different
language/framework. Once again, I’m going to play the “Not Rails’
fault” card. When you have developers with no database experience (and no
desire to learn about them) start developing database-backed web apps,
there’s going to be an major problem! RDBMS’s are extremely complicated and to
build a successful Rails app means you need to have at least a moderate
understanding of what is going on under the hood. Without that understanding,
your Rails app will never scale. But a little bit of study and appreciation for
what is really going on will allow you to quickly spot what is and what is not
acceptable Rails code.

Keeps these thoughts in mind and your Rails app will scream, scale, & [some
other s-word] all the way to becoming the next Twitter.