For cloud-based data backup, Microsoft Azure Backup is well suited for the ends of the company-size spectrum: small companies that don't have many servers, and large companies that will integrate it with System Center Data Protection Manager.
By far the easiest way to get an initial experience with Azure, "the Microsoft cloud," is by using it to back up one or more Windows servers. The procedure, while more involved than you might think, goes fairly quickly when you have a handy guide nearby (such as this white paper, I hope!). I tried out the service for my own company; the examples and screenshots here are from "real life."
Using Azure for backup isn't expensive (costs have come down since its introduction) and you get a free month, within usage limits, to experiment with it. If you like the experience, you can expand your Azure usage to include Web hosting, Active Directory, cloud-based virtual machines, and so on. And even if you don't explore Microsoft Azure further (note the recent rebranding from "Windows Azure"), you may find that the online backup piece fills a need in your disaster recovery strategy.
(Incidentally, aspirants to the Server 2012 MCSA certification will need to know about Azure Backup to pass the 70-412 exam.)
Clients and Workloads
In early 2015, Microsoft beefed up Azure Backup. Its capabilities at this writing include backing up Windows Server 2008 R2 SP1 and newer, System Center 2012 Data Protection Manager workloads (including Hyper-V, SQL Server, Sharepoint, and Exchange as long as you have DPM Update Rollup 5), 64-bit versions of Windows 8.x and Windows 7 SP1, and Windows Server Essentials 2012 and newer (which requires a different agent).
Note that without Data Protection Manager, Azure Backup is not supported for any workload other than file-and-folder backups. You cannot use Azure Backup to back up the system state, or to create a Bare-Metal-Restore (BMR) backup. You cannot back up network shares. Volumes to be backed up must be NTFS, and if you're using BitLocker, you must disable it before the backup.
The new (2015) size limit is 1.65 TB per backup. Retention policies now permit retaining backups for up to 99 years.
For the initial "seeding" of the cloud backup, you may not wish to back up over your network, in which case Microsoft offers the "offline backup" option that integrates with the Azure import/export service. You basically ship a disk to your friendly neighborhood Azure datacenter to create the first copy of your backup.
A key to overcoming institutional concerns about security in the cloud is encryption. Azure Backup requires a passphrase for encrypting data to be backed up. The agent performs encryption prior to transmission to Azure, and decryption after performing a restore operation back to the local system. Microsoft advises that it does not keep a copy of the passphrase. For additional security, servers must be registered to an Azure "vault" using verified credentials. When restoring data to the same server from which it was backed up, you don't have to supply the passphrase, but when restoring to a different server, you do. Microsoft can generate a passphrase for you, or you can create your own; in either case, you can change it in the console's Properties page later.
Azure Backup uses compression to reduce transmission time and storage requirements. As you might expect, the effectiveness of its compression depends on the compressibility of the content; in my test backup of 76 GB worth of ISO images, which are not very compressible, the compression ratio was very close to 1:1.
Azure Backup also uses block-level incremental backup methods so that only modified blocks are backed up in subsequent backups of the same set of files and folders. I wonder about its efficiency though: when I added a single 13KB file to my backup folder, Azure Backup's next backup was over 21MB, which seems like a lot of overhead. At each backup's conclusion, a verification step is performed, which was admirably quick in my testing.
For redundancy, Microsoft stores six copies of your backups, three in one datacenter and three in a geographically separate datacenter. They're all in the same country, but if an entire country goes offline, we probably have other problems.