Je tomu několik let, co jsem se snažil vyřešit problém synchronizace dat mezi různými zařízeními. Ať poznámky, projekty nebo multimédia, čas od času je potřeba mít určité soubory přístupné z několika zařízení. Samozřejmě je zde otázka, zda není vhodným řešením síťový server, který zpřístupní veškerá data online. Ovšem problém může být právě v tom, že být online nemusíme, anebo jsme nuceni využít pomalejších datových linek, případně jsou aplikována FUP pravidla.
Uživatelé Microsoft Windows se pravděpodobně setkali se speciální složkou „Aktovka“ (Briefcase). Tato funkcionalita je součástí Windows od verze Windows 95. Ve stručnosti slouží pro obousměrnou synchronizaci souborů mezi dvěma složkami. V novějších Windows 8 je tato funkcionalita označena za zastaralou a bude později odstraněna. Je to samozřejmě logický krok, jelikož Windows 8 integrují službu Microsoft OneDrive (původně SkyDrive), která pro synchronizaci využívá zdroje v cloudu. Ale o tom později.
V mém případě jsem aktovku zkoušel, ale aktivně nepoužíval. Hlavním důvodem bylo, že v mém portfoliu zařízení, kromě Windows, vždy figuroval i GNU/Linux a případně SUN Solaris.
Na straně všemožných UNIXů je jedním z nejpoužívanějších synchronizačních nástrojů rsync. Rsync je nástroj určený pro přenos souborů s možností přírůstkového módu. Dovoluje přenášet přístupová práva (včetně ACL), rozšířené atributy (XATTR), uživatelská oprávnění a podporuje síťový provoz (např. přes SSH, rsync server nebo připojené síťové zdroje). Utilita rsync je portována i na platformu Windows, a proto není problém vytvořit heterogenní infrastrukturu. Microsoft ve Windows Vista představil podobný nástroj, který se jmenuje Robocopy (nahrazuje xcopy). Robocopy pracuje s připojenými zařízeními, včetně síťových disků (podporuje UNC cesty – např. \\server\adresář
). V mém případě jsem používal jak rsync, tak Robocopy.
Postupem času jsem ale chtěl něco více. Nástroj, který nebude pracovat pouze s připojenými zdroji a bude možné jednoduše a bezpečně synchronizovat více adresářů najednou.
Dalším byl, dnes velmi populární, Dropbox. Jedná se o cloudový nástroj, který využívá serverové infrastruktury pro ukládání dat. S touto infrastrukturou jsou synchronizovány veškeré změny na zařízeních. Veškerá komunikace serverů a klientů přes internet je šifrována. Omezením Dropboxu je velikost neplaceného úložného prostoru, jelikož není možné využít vlastní infrastruktury jako serveru.
Podobné vlastnosti jako Dropbox má i Microsoft OneDrive (dříve SkyDrive). OneDrive je součástí Windows od verze Windows 8.1 a Microsoft Office od verze Office 2013/Office 365. Ve Windows 10 a Office 16 byla představena další úroveň integrace, kdy je možné velice jednoduché vytvořené dokumenty sdílet mezi dalšími uživateli. Samozřejmě to bylo možné ve Windows 8.1 či Office 2013, nicméně ve Windows 10 a Office 16 je tato vlastnost posunuta ještě dále. Výhodou OneDrive je tedy automatická podpora operačního systému a kancelářského balíku. Uživatel může pracovat jak s „vlastním“ (v datovém centru Microsoftu přiděleném pouze jemu) internetovým úložištěm nebo úložištěm firemním. Je tedy podporována funkce práce v týmech. Ve firemním prostředí je velmi užitečnou vlastností propojení s Active Directory (jak on-premise tak Microsoft Azure) a možnost definování vlastních globálních politik.
Díky otevřenému API je možné vytvářet vlastní aplikace spolupracující s Dropboxem i OneDrive. Existuje proto nepřeberné množství projektů pro Windows, GNU/Linux, Android, Max OS X a iOS a další operační systémy.
Se svoji vlastní infrastrukturou jsem ale požadoval něco více. Používání Dropboxu a později OneDrive bylo spíše kompromisem. Při snaze o vyřešení tohoto kompromisu jsem narazil na Open Source projekt ownCloud. Ten využívá vlastní serverové infrastruktury (server si tedy nainstalujeme dle našeho uvážení) a klientské aplikace, tedy podobně jako v případě Dropboxu. U obou těchto produktů chybí větší integrace s operačními systémy, což je logické. Toto výhodu má pouze OneDrive.
Na ownCloud mě opravdu lákala možnost využití vlastního serveru. Řešení klient-server jsem ale využíval u OneDrive. Nikde ale nebyl produkt, který by poskytoval to, po čem jsem vždy po očku pokukoval:
- kompletně vlastní infrastruktura,
- bezpečná šifrovaná komunikace,
- synchronizace mezi zařízeními bez nutnosti vlastnit server,
- možnost definovat master node,
- synchronizace více adresářů kdekoli v systému,
- multiplatformní (Windows, GNU/Linux, Android),
- práce za NAT,
- není nutná přílišná provázanost se systémem jako v případě OneDrive.
Trvalo to několik let, než jsem narazil na produkt, který má přání vyslyšel. Byl jím BitTorrent Sync. Výborná filozofie a i přes několik počátečních problémů poměrně kvalitní nástroj. BTsync jsem využíval k synchronizaci projektů, programů, hudby, soukromých dat a nastavení serverů a aplikací. To bylo ještě v době, kdy byl BTsync ve stádiu beta testování. Bohužel ale přišla změna a z prakticky neomezených možností dostala finální verze řadu limitů. Ve stejnou dobu ale uviděl světlo světa komunitní projekt Syncthing.
Syncthing je, stejně jako BTsync, decentralizovaným řešením, na kterém se velmi intenzivně pracuje. Velkou výhodou je zveřejňování zdrojových kódů. Mám rád Open Source projekty, ale striktně se nevyhýbám ani proprietárním. V tomto ohledu se snažím být objektivní a v první řadě eliminovat možná bezpečností rizika pří provozování systémů a následnou práci s daty. Zdrojové kódy u Syncthing jsou pro mě důležité z toho důvodu, že na jednom bodě provozuji jako server zařízení Alix (s CPU AMD Geode), což je architektura i586. Bohužel i586 není Arch Linuxem přímo podporována a dostupná ± kompatibilní je i686. Nasadil jsem proto ji. Rozdíl je v podpoře několika málo CPU instrukcí, a to zejména pro matematické operace. Bohužel Syncthing je v repositáři Arch Linuxu zkompilován právě s těmito instrukcemi a na Alixu nepracuje. Každou vydanou verzi si proto musím překládat ze zdrojových kódů ručně sám.
Momentálně má Syncthing oproti BTsync menší paměťové nároky. V případě Alixu s 256 MB RAM je to rozhodně zapotřebí. Nevýhodou je nemožnost používat aplikaci za technoligií NAT, pokud nemáme v síti podporu UPnP (otevření komunikačního portu firewallu/routeru směrem k naší aplikaci); Syncthing nemá v síti Internet veřejné servery, které by tento přenos, jako v případě BTsync, umožnily. (2016-07-15: Syncthing je již nějakou dobu možné používat i za NAT. Infrastruktura obsahuje tzv. veřejné relay servery. Takový server můžeme nainstalovat i v režimu public, tedy pouze pro naše účely v naší síti nebo internetu.) Jak jsem ale již psal, na projektu se velmi intenzivně pracuje a kromě přidávání nových funkcí se ve vydáních samozřejmě řeší aktuální chyby (viz oprava mnou nahlášeného problému).
A to byla má cesta k, snad na dlouhou dobu, poslednímu nástroji: Syncthing…
Jen možná pár poznámek: Synchronizace není přesně to samé jako kopírování a rozhodně neslouží pro zálohování dat. V případě porušení integrity nebo výmazu dat je tato změna přenesena na ostatní zařízení. I když, já synchronizaci využívám u svého robustního zálohovacího řešení. Ale o tom třeba někdy jindy.