Synchronization and backup programs

From ArchWiki
Jump to: navigation, search

This page lists and compares applications that synchronize data between two or more locations, and those that build on top of such functionality to make incremental copies of important data for backup purposes. Because of their relationship, the two groups share several traits that justify describing them in the same article.

Backup overview

Having backups of important data is a necessary measure to take, since human and machine processing errors are very likely to generate corruption as time passes, and also the physical media where the data is stored is inevitably destined to fail. In order to choose the best program for one's own needs, the following aspects should be considered:

  • The type of backup medium that is going to store the data, e.g. CD, DVD, remote server, external hard drive, etc.
  • The planned frequency of backups, e.g. daily, weekly, monthly, etc.
  • The features expected from the backup solution, e.g. compression, encryption, handles renames, etc.
  • The planned method to restore backups if needed.

Data synchronization

These applications simply keep directories synchronized between multiple locations/machines, in a "mirror" fashion. Nonetheless, most of them still allow storing and reverting to old revisions of modified or deleted files.

See also:

Legend:

  • Name: the application name, linking to the ArchWiki article or the official website.
  • Installation: a link to the package.
  • Implementation: the programming language, library, or utility that the application is based on.
  • Delta transfer: only the modified parts of files are transferred.
  • Encrypted transfer: data is encrypted by default when transferred over the network.
  • FS metadata: file system permissions and attributes are synchronized.
  • Resumable: the synchronization can be resumed if interrupted.
  • Handles renames: moved/renamed files are detected and not stored or transferred twice. It typically means that a checksum of files or its chunks is computed.
  • Version control: the old version of files are backed up (reverse incremental backup).
  • Change propagation: specifies in how many directions changes can be propagated.
    • unidirectional means one-way synchronization of two locations,
    • bidirectional means two-way synchronization of two locations and
    • multidirectional means full synchronization of more than two locations.
  • Conflict resolution: the application handles file conflicts, either automatically or interactively, i.e. it does not silently discard conflicting files. This attribute does not apply to applications that only propagate changes in one direction.
  • FS monitoring: the application listens to file system events to trigger the synchronization.
  • CLI: the application is command-line driven, i.e. it is scriptable.
  • Other interfaces: the application has the specified user interfaces, e.g. GUI, TUI, or web-based.
  • License: the license of the server and client applications.
  • Other platforms: supported operating systems other than Linux.
  • Specificity: brief notes about special features that notably set the application apart from the others.
Name Installation Implementation Delta transfer Encrypted transfer FS metadata Resumable Handles renames Version control Change propagation Conflict resolution FS monitoring CLI Other interfaces License Other platforms Maintained Specificity
Resilio Sync rslsyncAUR  ? (closed source) Yes Yes  ? Yes  ? Yes multidirectional  ?  ? No Web Proprietary freemium FreeBSD, Windows, macOS, Android, iOS, Windows Phone, Amazon Kindle Fire Yes P2P sync
FreeFileSync freefilesyncAUR C++  ? SFTP [1]  ?  ? Yes [2] Yes [3] unidirectional / multidirectional Yes  ? No Yes GPL Windows, macOS Yes
git-annex git-annex Haskell, git rsync [4] rsync [5]  ?  ?  ? Yes multidirectional; with git remotes [6] renames conflicting files [7]  ? Yes git-annex assistant GPLv3 macOS, Android Yes Manage files with git
osync.sh osyncAUR Bash, based on rsync rsync rsync  ? Yes No Yes bidirectional keeps multiple versions of a file [8] optional [9] Yes No BSD Yes
rclone rclone Go No [10]  ?  ?  ?  ?  ? unidirectional [11]  ?  ? Yes RcloneBrowser MIT *BSD, Plan9, Solaris, Windows, macOS Yes Optimized for synchronization with cloud storage, behavior varies with the features supported by the remote location.
rdiff-backup rdiff-backup Python 2, librsync rsync rsync Yes  ? No Yes unidirectional No Yes No GPL Win32  ?
rsync rsync C Yes SSH or native protocol Yes Yes No
  • --link-dest with hard links [12]
  • --backup
unidirectional No Yes Rsync#Front-ends GPLv3 Win32 Yes Standard tool present on all Linux distributions.
SparkleShare sparkleshare C#, git Yes AES-256 [13]  ?  ? Yes Yes  ?  ?  ? No Yes GPLv3 Windows, macOS Yes It can sync with any Git server over SSH.
Syncany syncanyAUR Java  ?  ?  ?  ?  ?  ?  ?  ?  ? Yes Yes GPLv3 No [14]
Syncthing syncthing Go Yes [15] Yes [16] partial [17] Yes  ? Yes [18], previous versions moved to archive folder multidirectional renames one file [19] Yes Yes Web, GTK MPL v2 BSD, Windows, macOS, Android, Kindle Paperwhite Yes P2P sync
Synkron synkronAUR C++  ?  ?  ?  ?  ?  ? multidirectional  ?  ? No Qt GPLv2 Windows, macOS No
taskd taskdAUR C++, Python Yes Yes  ? Yes  ?  ? multidirectional  ? No Yes No MIT Android Yes
Unison unison OCaml Yes Yes partial [20] optional [21] No Yes [22] bidirectional interactive No Yes GTK2 GPL FreeBSD, Windows, macOS, Android Yes [23]

Incremental backups

Applications that can do incremental backups remember and take into account what data has been backed up during the last run (so-called "diffs") and eliminate the need to have duplicates of unchanged data. Restoring the data to a certain point in time would require locating the last full backup and all the incremental backups from then to the moment when it is supposed to be restored. This sort of backup is useful for those who do it very often.

See also:

Legend:

  • Name: the application name, linking to the official website.
  • Installation: a link to the main ArchWiki article, if existing, or directly to the package pages.
  • Implementation: the programming language, library, or utility that the application is based on.
  • Compressed storage: compression is used for storage.
  • Encrypted storage: encryption is used for storage.
  • Delta transfer: only the modified parts of files are transferred.
  • Encrypted transfer: data is encrypted by default when transferred over a network.
  • FS metadata: file system permissions and attributes are backed up.
  • Easy access: the backup is stored plainly in the file system, or is mountable as such.
  • Resumable: the backup can be resumed without restarting it if interrupted.
  • Handles renames: moved/renamed files are detected and not stored or transferred twice; it typically means that a checksum is computed for files or chunks thereof.
  • CLI: the application is command-line driven, i.e. it is scriptable.
  • Other interfaces: the application has the specified user interfaces, e.g. GUI, TUI, or web-based.
  • Licence: the licence of the server and client applications.
  • Other platforms: supported operating systems other than Linux.
  • Specificity: brief notes about special features that notably set the application apart from the others.

Single machine

These applications are aimed at backing up data from the machine they are installed on, although the backup destination can be located on an external machine or storage media.

Chunk-based increments

If a file is modified, these applications store only its changed parts at the next snapshot. Compared to #File-based increments applications, these are more space-efficient, especially when large files receive small modifications; on the other hand, the archived snapshots have to be opened with the backup application that created them, since the files have to be reconstructed from the stored binary diffs.

Name Installation Implementation Compressed storage Encrypted storage Delta transfer Encrypted transfer FS metadata Easy access Resumable Handles renames CLI Other interfaces Licence Other platforms Maintained Specificity
Areca Backup arecaAUR Java Zip, Zip64 AES128, AES256 Yes Yes Yes No Pausing only No Yes Yes GPLv2 Windows Yes
BorgBackup borg Python, C (Cython) lz4, zlib, lzma, zstd AES256 Yes SSH Yes [24] Yes [25] Yes [26] Yes Yes third party BSD *BSD, macOS, Windows (Cygwin / WSL)[27] Yes Deduplication based on variable length chunks; support both local and SSH-based remote backup destination.
btar btarAUR[broken link: archived in aur-mirror] C Yes Yes Yes Yes  ? No  ?  ? Yes No GPLv3 Yes Redundancy, indexed extraction, multicore compression, input and output serialisation, tolerance to partial archive errors.
bup bup bup-gitAUR C, Python, git Yes No Yes Yes Immature Yes [28] pick up where you left off [29] Yes Yes third party GPLv2 NetBSD, Windows, macOS Yes Same storage format as git.
bups bupsAUR bup front-end Yes No Yes Yes Immature Yes pick up where you left off [30] Yes Yes GTK 3 MIT Yes
Déjà Dup Déjà Dup duplicity front-end Yes Yes Yes Yes  ? No Yes No Yes GTK+ GPLv3 Yes Integrated into GNOME Files.
Duplicati duplicati-latestAUR C# Yes Yes Yes Yes scheduled for 2.0 release No Pausing only No Yes Yes LGPL Windows Yes
Duplicity Duplicity librsync gzip gpg Yes Yes  ? No Yes No Yes Déjà Dup GPL Yes
Duply Duply duplicity front-end Yes Yes Yes Yes  ? No Yes No Yes No GPLv2 Yes
Kup Backup System kup rsync, bup front-end Yes Yes Yes Yes Immature Yes No Yes bup Qt GPLv2 Yes
obnam obnamAUR Python Yes GnuPG Yes Yes  ? Yes checkpoints every 100MB  ? Yes No GPLv3 No
restic restic restic-gitAUR Go No [31] AES-256 [32] Yes Yes Yes [33] Yes [34] Yes [35] Yes Yes No [36] BSD OpenBSD, Windows, macOS Yes Supports storage on various cloud services natively and through rclone.
ZBackup zbackupAUR C++ LZMA, LZO AES Yes Yes  ? planned [37] No Kinda through tar Yes No GPLv2 Yes Repository consists of immutable files.

File-based increments

If a file is modified, these applications store its new version entirely at the next snapshot. Compared to #Chunk-based increments applications, these are less space-efficient, especially when large files receive small modifications; on the other hand, often the archived snapshots can be opened without the need to have the backup application installed.

Specific legend:

  • Hard links: whether unmodified files are stored as hard links to previous versions.
Name Installation Implementation Compressed storage Encrypted storage Delta transfer Encrypted transfer FS metadata Easy access Resumable Handles renames Hard links CLI Other interfaces Licence Other platforms Maintained Specificity
Back In Time Back In Time Python, rsync, diff No No rsync rsync rsync Yes No No Yes [38] Yes Qt GPLv2 Yes
DAR (Disk ARchive) darAUR C++ special archive format Yes Yes Yes  ?  ?  ?  ? No [39] Yes DarGUI GPL FreeBSD, NetBSD, Windows, macOS Yes
DarGUI darguiAUR DAR front-end Yes Yes Yes Yes  ?  ?  ?  ? No [40] No GTK GPL Windows  ?
hdup[dead link 2016-07-11] hdupAUR C bzip, gzip, lzop gpg  ? SSH  ? No No No No Yes No GPLv2 No Multiple backup targets.
Link-Backup link-backupAUR Python No No  ? SSH  ?  ? Yes Yes No [41] Yes No MIT No It copies itself to the server.
rdup rdupAUR C tar.gz gpg, blowfish and others  ?  ?  ? Yes  ? No Yes Yes No GPLv3 No Set of command-line tools.
rsnapshot rsnapshot rsync No No Yes Yes  ?  ?  ?  ? Yes [42] Yes No GPLv2 Win32 Yes
sbackup sbackupAUR Python gzip, bzip2 No  ? SSH  ? No No No No No GTK GPLv3 Yes
TimeShift timeshiftAUR rsync No No rsync rsync  ?  ?  ?  ? Yes No GTK GPLv3 Designed for full-system backups to dedicated devices. Yes

Network oriented

These applications have been designed to centralize the backup of several machines connected to a network, through a server-client model. In general they are more complicated to deploy, compared to #Single machine solutions.

Specific legend:

  • Control direction: Pull: server logs into client. Push: client initiates backup session.
  • Increment type: the strategy used to reduce used space by deduplicating data (i.e., besides compression).
    • file-based: if a file is modified, the entire new version is stored at each snapshot.
      • hard-links: whether unmodified files are stored as hard links to previous versions.
    • chunk-based: only the modified parts of files are stored at each snapshot.
Name Installation Implementation Control direction Compressed storage Encrypted storage Delta transfer Encrypted transfer FS metadata Easy access Resumable Handles renames Increment type CLI Other interfaces Licence Other platforms Maintained Specificity
BackupPC BackupPC Perl Pull Yes No Yes Yes Yes No Yes  ? file-based, hard links [43] No Web GPLv2 Any (no client needed) Yes Identical files across backups of the same or different clients are stored only once.
Bacula bacula* in AUR C++ Pull Yes Yes  ? Yes  ?  ? Yes  ? file-based [44] Yes GUI, Web AGPLv3 Windows, macOS Yes
burp burp-backupAUR librsync Push Yes Yes Yes Yes  ?  ?  ?  ? chunk-based [45] Yes burp-ui AGPLv3 Windows Yes
SafeKeep safekeepAUR rdiff-backup Pull No No  ? Yes  ?  ?  ?  ? chunk-based [46] Yes Yes GPL No Integrates with LVM and databases to create consistent backups. Bandwidth throttling.
Snebu snebuAUR[broken link: archived in aur-mirror] C Push or Pull Yes No  ? Yes  ?  ?  ?  ? file-based [47] Yes No GPLv3  ? Supports arbitrary retention schedules.
Synbak synbak Multitool wrapper  ? Yes No Yes Yes Yes  ?  ?  ?  ? No Web GPLv3 Yes Unifies several backup methods.
UrBackup urbackup* in AUR C++ Pull No No Yes Internet transfers only Yes Yes Yes Yes file-based,hard-links and symlinks[48]/chunk-based CoW-Snapshots[49] Yes (client) GUI, Web AGPLv3+ Windows, macOS Yes Identical files across backups of the same or different clients are stored only once. Integrates with LVM, dattobd and btrfs for file system snapshots.

Version control systems

These are traditionally used for keeping track of software development; but if you want to have a simple way to manage your config files in one directory, it might be a good solution.

See List of applications/Utilities#Version control systems and Dotfiles#Version control.

See also