DAR

It has been tested under Linux, Windows, Solaris, FreeBSD, NetBSD, MacOS X and several other systems and is released under the GNU General Public License (GPL). It relies on the libdar library and its APplication Interface (API), which is the core part of dar programs; as such, this library is released under the GPL along with dar. Consequently, to use the API, your program must be released under the GPL as well. Some external programs do rely directly on libdar or on the dar command-line tool to provide Graphical User Interfaces (GUI).

Hard Link Consideration

Hard links are properly saved in any case and properly restored if possible. For example, if restoring across a mounted file system, hard linking will fail, but dar will then duplicate the inode and file contents, issuing a warning. Hard link support includes the following inode types: plain files, char devices, block devices, symlinks (Yes, you can hard link symbolic links.

Sparse Files

By default Dar takes care of sparse files, even if the underlying filesystem does not support sparse files(!). When a long sequence of zeroed bytes is met in a file during backup, those are not stored into the archive but the number of zeroed bytes is stored instead (structure known as a "hole"). When comes the time to restore that file, dar restores the normal data but when a hole is met in the archive dar directly skips at the position of the data following that hole. If the underlying filesystem supports sparse files, this will (re)create a hole in the restored file, making a sparse file. Sparse files can report to be several hundred gigabytes large while they need only a few bytes of disk space, being able to properly save and restore them avoids wasting disk space at restoration time and in archives.

Dirty Files

At backup time, dar checks that each saved file had not changed at the time it was read. If a file has changed in that situation, dar retries saving it up to three times (by default) and if it is still changing, is flagged as "dirty" in the archive, and handled differently from other files at restoration time. The dirty file handling is either to warn the user before restoring, to ignore and avoid restoring them, or to ignore the dirty flag and restore them normally.

Note that dar precision when readng/writing inode dates (atime, ctime, mtime, birthtime) is the microsecond. Thus a file is seen as having changed even if a very small modification occurres in it very frequently.

Complete list of features can be found here.