Synchronization and backup programs: Difference between revisions

From ArchWiki
VisualWikitext
(Added a column listing the supported storage backends for the various packages.)
(Undo revision 525545 by Jernst (talk) - useless bloat which makes the table 5 times longer)
Line 380: Line 380:
! Maintained
! Maintained
! Specificity
! Specificity
! Backup to
|-
|-
| [http://areca.sourceforge.net/ Areca Backup]
| [http://areca.sourceforge.net/ Areca Backup]
Line 399: Line 398:
| {{Yes}}
| {{Yes}}
|
|
| Local drive, network drive, USB, FTP, FTPS, SFTP server
|-
|-
| [http://borgbackup.readthedocs.org/en/stable/ BorgBackup]
| [http://borgbackup.readthedocs.org/en/stable/ BorgBackup]
Line 418: Line 416:
| {{Yes}}
| {{Yes}}
| Deduplication based on variable length chunks; support both local and SSH-based remote backup destination.
| Deduplication based on variable length chunks; support both local and SSH-based remote backup destination.
| Local drive, remote drive via ssh
|-
|-
| [http://viric.name/cgi-bin/btar btar]
| [http://viric.name/cgi-bin/btar btar]
Line 436: Line 433:
|  
|  
| {{Yes}}
| {{Yes}}
| Redundancy, indexed extraction, multicore compression, input and output serialisation, tolerance to partial archive errors.
| Redundancy, indexed extraction, multicore compression, input and output serialisation, tolerance to partial archive errors.  
| Local drive
|-
|-
| [https://bup.github.io/ bup]
| [https://bup.github.io/ bup]
Line 456: Line 452:
| {{Yes}}
| {{Yes}}
| Same storage format as git.
| Same storage format as git.
| Local drive, remote drive executing bup via ssh
|-
|-
| [https://github.com/emersion/bups bups]
| [https://github.com/emersion/bups bups]
Line 475: Line 470:
| {{Yes}}
| {{Yes}}
|
|
| See bup
|-
|-
| [https://launchpad.net/deja-dup Déjà Dup]
| [https://launchpad.net/deja-dup Déjà Dup]
Line 494: Line 488:
| {{Yes}}
| {{Yes}}
| Integrated into [[GNOME Files]].
| Integrated into [[GNOME Files]].
| See duplicity
|-
|-
| [http://www.duplicati.com/ Duplicati]
| [http://www.duplicati.com/ Duplicati]
Line 513: Line 506:
| {{Yes}}
| {{Yes}}
|
|
| Local drive, ftp, OpenStack Swift, sftp, Amazon Cloud Drive, Azure, B2 Cloud Storage, Box.com, Dropbox, Google Cloud Storage, Google Drive, HubiC, Yottacloud, Mega.nz, Microsoft Office 365, Microsoft OneDrive, Microsoft Sharepoint, Rackspace Cloudfiles, Rclone, Sia, Tahoae-LAFS
|-
|-
| [http://www.nongnu.org/duplicity/ Duplicity]
| [http://www.nongnu.org/duplicity/ Duplicity]
Line 532: Line 524:
| {{Yes}}
| {{Yes}}
|
|
| local drive, acd_cli, Amazon S3, Backblaze B2, Copy.com, DropBox, ftp, GIO, Google Docs, Google Drive, HSI, Hubic, IMAP, Mega.co, Microsoft Azure, Microsoft Onedrive, par2, Rackspace Cloudfiles, rsync, Skylabel, ssh/scp, SwiftStack, Tahoe-LAFS, WebDAV
|-
|-
| [http://www.duply.net/ Duply]
| [http://www.duply.net/ Duply]
Line 551: Line 542:
| {{Yes}}
| {{Yes}}
|
|
| See duplicity
|-
|-
| [http://kde-apps.org/content/show.php/Kup+Backup+System?content=147465 Kup Backup System]
| [http://kde-apps.org/content/show.php/Kup+Backup+System?content=147465 Kup Backup System]
Line 570: Line 560:
| {{Yes}}
| {{Yes}}
|
|
| See rsync, bup
|-
|-
| [https://obnam.org/ obnam] ("Retired")
| [http://liw.fi/obnam/ obnam]
| {{AUR|obnam}}
| {{AUR|obnam}}
| Python
| Python
Line 588: Line 577:
|  
|  
| {{No}}
| {{No}}
|
|  
|  
|-
|-
Line 608: Line 596:
| {{Yes}}
| {{Yes}}
| Supports storage on various cloud services natively and through {{Pkg|rclone}}.
| Supports storage on various cloud services natively and through {{Pkg|rclone}}.
| Local disk, sftp, REST, Amazon S3, Minio, OpenStack Swift, Backblaze B2, Microsoft Azure, Google Cloud Storage, other Services via rclone
|-
|-
| [http://zbackup.org/ ZBackup]
| [http://zbackup.org/ ZBackup]
Line 627: Line 614:
| {{Yes}}
| {{Yes}}
| Repository consists of immutable files.
| Repository consists of immutable files.
| Local disk
|}
|}


Revision as of 04:57, 11 June 2018

Related articles

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: Template: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: Template: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

Retrieved from "https://wiki.archlinux.org/index.php?title=Synchronization_and_backup_programs&oldid=525550"