Vaulting Changes in Alike 4.0

Alike 4.0 has been in the works since early this year and many of you may have heard of its two main features, which is a web-based UI that supersedes the Windows standalone desktop app and new offsite vaulting support for Amazon S3.

Of course Alike 4.0 has many other new features and benefits, especially around overall manageability and easy of use, but for this post I’d like to get under the hood of Alike vaulting prior to 4.0 and what’s changing in 4.0.

Alike’s offsite vaulting is a powerful feature, allowing you to send some or all of your backups to a secondary storage location for added redundancy and disaster recovery. Because it sends data in Alike’s deduplicated data format, it’s pretty network-efficient, especially if you have common data across your VM infrastructure, and once you get the first round of vaults sent, it’s a  great way to be prepared for the worst going forward.

Since Alike 2.6, Alike has leveraged CIFS (aka SMB or Windows file sharing) as the transfer protocol for offsite vaulting. This has made vaulting easy to deploy and manage, since all you need is a CIFS share that’s network-accessible in order to get started. Vaulting works by tracking which data blocks had been written or deleted to journals that are shipped along side the block data itself. Periodically, using a maintenance job, Alike applies these journals to an offsite database in order to keep onsite and offsite synced up with one another, so if your Alike installation is ever lost, you can reconnect another Alike install to your offsite location and pick up where you left off with vaulting.

This system works pretty great but had a few issues. In particular, the existing vaulting code is pretty chatty with journal files, and sends dozens or even hundreds of these journals per VM. While all told they don’t add up to much in terms of disk/network consumption, they do consume extra I/O operations. Also some Windows clients, especially desktop systems, had trouble due to Windows file caching, which created a nuisance around flushing file buffers in order to force these files out of kernel cache.

This chattiness was also a design problem for Amazon S3, where customers are metered for all I/O operations against the cloud. So Quadric engineering went back to the drawing board to redesign vaulting to use coarser-grained journaling that utilizes fewer operations to accomplish the same outcome. This not only cuts down on I/O but also is a more robust design, since fewer moving pieces is always a good thing. As a further upside, maintenance, such as reconciliation and purge, are much faster since there are fewer transactions to contend with.

Some engineering love also went into the CIFS-specific code paths as well. Vaulting is reengineered to use Windows overlapped I/O instead of blocking calls. Thus vaulting consumes fewer system resources while scaling better when you are vaulting on a LAN.

For those interested in getting off CIFS and into cloud storage, Amazon S3 is a very attractive destination for backup data because of its built-in redundancy and data integrity. All Alike data sent to S3 is checked cryptographically on upload, making it especially resistant to corruption.

Of course different organizations have different needs and different budgets for offsite storage, but by improving our vaulting protocol and adding S3 support, we hope to give you more powerful options going forward.

Easy To Install. Easy To Use. Free To Try.