Gorsync Backup is a best GTK+ frontend for brilliant RSYNC console utility. Simple, but powerful. Written completely in Go programming language, provides responsive GUI design and intuitive interface. Might be used as training material how to write rich multi-threaded GUI application with GTK+ in Golang.
$ go get -u github.com/d2r2/go-rsync
$ sudo ./ui/gtkui/gs_schema_install.sh
Alternative approach to install application is to downloads installation packages from latest release, which can be found in release page . You may find there packages for deb (Debian, Ubuntu), rpm (Fedora, Redhat) and pkg.tar.xz (Arch linux) Linux distributives.
One can be found in AUR repository https://aur.archlinux.org/ by name "gorsync-git" to download, compile and install latest release. On Archlinux you can use any AUR helper to install application, for instance
yaourt -S gorsync-git .
v0.3.1 (latest release):
Short list of preliminary anticipated features for next releases:
As in regular RSYNC session, Gorsync Backup is doing same job: copy files from one location (source) to another (backup destination). For instance, real life scenario would be: backing up your data from home NAS to flash hard drive attached to your notebook.
Gorsync Backup can copy from multiple RSYNC sources at once. It could be your pictures, movies, document's from home NAS, routers and smart Linux device configuration files (/etc/... folder) and so on... Thus Gorsync Backup profile let you specify multiple separated RSYNC URL sources to get data from in single backup session and combine them all together in one destination place.
Gorsync Backup never overwrite existing backup session destination, but use same common target root path, to put data near. For instance, your flash drive backup folder content might looks like:
$ <destination root folder to stores backup content> $ ↳ ~rsync_backup_20180801-012237~ $ ↳ ~rsync_backup_20180802-013113~ $ ↳ ~rsync_backup_<date>-<time>~ ... $ ↳ ~rsync_backup_20180806-014036~ $ ↳ ~rsync_backup_(incomplete)_20180807-014024~
, where each specific backup session stored in separate folder with date and time in the name. "(incomplete)" phrase stands for backup, that occures at the moment. Once backup will be completed, "(incomplete)" will be removed from backup folder name. Another scenario is possible, when backup process has been interrupted for some reason: in this case "(incomplete)" phrase will never get out from folder name. But, in any case it's easy to understand where you have consistent backup results, and where not.
$ <root folder to store backup contents on flash drive> $ ↳ ~rsync_backup_20180801-012237~ $ ↳ ~backup_log~.log $ ↳ ~backup_nodes~.signatures $ ↳ <folder with rsync source #1 content> ... $ ↳ <folder with rsync source #N content>
~backup_log~.log file describe all the details about the steps occurred, including info/warning/error messages if any took place.
~backup_nodes~.signatures file contains hash imprint for all source URLs, to detect in future backup sessions same data source for "deduplication" purpose.
Once you start using Gorsync Backup on regular basis (daily/weekly/monthly), you will find soon that your backup storage will be filled with sets of almost same files (of course changes over time will provides some relatively small deviation between data sets). This redundancy might quickly exhaust your free space, but there is a real magic exists in modern file systems - "hard links"! Hard links allow do not spent space for files, which have been found in previous backup sessions unchanged. Additionally it's significantly speed up backup process. The collaboration of Gorsync Backup with RSYNC know how to activate this feature. Still you have possibility to opt out this feature in application preferences, but in general scenarios you don't need to do this.
Remember, that such legacy file systems as FAT, does not support "hard links", but successors, such as NTFS, Ext3, Ext4 and others have "hard links" supported. So, think in advance which file system to choose for your backup destination.
Note : Gorsync Backup and RSYNC has some limitations with "deduplication" - they can't track file renames and relocations inside backup directory tree to save space and time in next backup session. This is not the application problem, it's RSYNC utility limitation. There is some experimental patches exist to get rid of this limitation, but not in the public RSYNC releases: you can read this and this .