Daniel Shakhmundes‘ Remote Backup service uses one of two methods for backup system implementations:

1. Typical/Stock/Default/Traditional software applications for Microsoft Windows platforms coupled with open source networking and data storage solutions.  The latter generally offers higher-performance, better security, and greater reliability over the the former, which is actually the weakest link in the scenario, but many businesses and clients are programmed to think Microsoft-centric.  Using the most easily-available, common, and therefore popular backup software (i.e. ntbackup.exe) delivers the best results with plenty of support to get the data out for backup, followed by superior solutions for transportation and storage once the data is liberated from the clutches of a Microsoft environment.
2. Outside of the Microsoft Windows world, business users rarely encounter any computer operating systems beyond than Apple’s Mac OS X, which is based on open source technology.  Even though Mac OS is Apple’s proprietary operating system, it is based on BSD (i.e. FreeBSD, OpenBSD, NetBSD, etc.) as of version “X”, which happens to their best one yet.  Of course, open source backup solutions rule in their own realm.  Where the plethora of Linux & BSD distributions are concerned, D.Shak chooses to use the open source software that strives to combine the best features of a mirror and an incremental backup; rdiff-backup.

The thing is, we want to provide the benefits of incremental mirroring/backup to the first scenario without the restrictive licensing and extortive costs of proprietary software.  The good news is that rdiff-backup is almost ready for doing so, and some already say it is.  Here’s a pseudo-log of D.Shak’s research & experiment this weekend:

Now available on rdiff-backup’s home page is a native Windows executable/binary as of version 1.2.2, released October 19th 2008 (currently the new stable version).  So, we now have Windows support for rdiff-backup by the developers!  All of the required libraries and modules are built-in, so there is no longer a need for Cygwin or other 3rd party software on Windows – these issues prevented D.Shak from providing clients a stable and well-supported solution using rdiff-backup.

Reading further, the rdiff-backup wiki (RdiffBackupWiki) seems up-to-date and is loaded with valuable information, including a BackupFromWindowsToLinux page that D.Shak reviewed and followed for experimentation.  We backuped up a Windows XP Professional workstation named Used on the home-office network.  Having already used PuTTY abundantly, the advice & directions provided in a How-To style were well suited to our usual ways.  Using Simon Tatham‘s putty.exe, puttygen.exe, and plink.exe, a secure/encrypted network connection/tunnel for rdiff-backup was established to a Linux-based server in the home-office named Sonic.

While the experiment was successful for the most-part, there were errors/warnings that we feel are not acceptable in the level of quality we deliver to our clients.  While some of the issues may be relatively easily or quickly resolvable, we don’t want to bleed on cutting-edge technology unless there is a lot of support available, either through a vibrant community of developers & users or funding (by client or stakeholder) to spend time and/or engage specialists.  The Daniel Shakhmundes business balances these considerations based on customers’ desires, delivering the best possible solutions according to each clients’ circumstances.

For the rdiff-backup developers, one of D.Shak’s concerns is the issues relating to hard-links and inodes.  Contemporary Microsoft Windows systems normally use the NTFS file-system, which is significantly different on a technical-level from the the open source ones that rdiff-backup is most attuned to.  rdiff-backup version 1.2.2 was supposed to automatically detect when it was backing up from a Windows file-system, which does not use inodes, but we found that symptoms/issues manifested when we did not use the –no-hard-links option.  This circumstance did not inspire confidence.

Another considerable deficiency is the inability to read files in certain circumstances, particularly
1)  open or “locked” in-use files, and/or
2)  those with permissions restricting read-access.
These are old and typical challenges for backup systems, and in the Windows/NTFS world they have Microsoft’s Volume Shadow Service (VSS) to surmount them.  However, rdiff-backup is not programmed to use VSS, and provides no alternative methods or means of its own.

D.Shak assembled a trail of web-pages that offer a solution to making use of the Volume Shadowing service at your own discretion, which reportedly works:

1. A bit of black magic: How to assign drive letters to VSS shadow copies… on Windows XP !
   http://blogs.msdn.com/adioltean/archive/2006/09/18/761515.aspx
2. DOSDEV.EXE – a misterious tool
   http://blogs.msdn.com/adioltean/archive/2005/10/04/477164.aspx
3. A TechArena message forum post by Sean Cai, MCSE2000, Microsoft Online Partner Support
   http://forums.techarena.in/windows-server-help/834524.htm#post3235029
4. Overview of the Microsoft Configuration Capture Utility (MPS_REPORTS)
   http://support.microsoft.com/kb/818742
5. Download details: Microsoft Product Support’s Reporting Tools
   http://www.microsoft.com/downloads/details.aspx?FamilyId=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0

There is a lot of other work to do before D.Shak has the time to further experiment.  Hopefully the rdiff-backup developers and the open source community appreciate this blog/post in the meanwhile.  Some people will inevitably polish the functionality & usability of rdiff-backup on Windows, and we will be there to help and benefit too!