rsync är en best om man kommer från windows-världen och van med snygga GUI, men har man gått på ett par snytingar och förlorat filer med backupprogram som visade sig att inte göra det som lovats och är luttrad så är det 'rsync' man använder i fortsättningen för att synka filträn mot varandra och mot backup för att vara _säker_ på att få jobbet gjort. Jobbar man i linux/unix-världen så är det rsync som gäller när man speglar filträd.
Rsync kan också prata SSH mot SSH-konton för skyddad datatransport och att få filerna till lagring som är omöjlig för windowsbaserade ransomware att komma åt.
I stort sett alla köpeNAS, och linuxbaserade lagring/servrar kan SSH öppnas så att NAS kan köras via SSH för tex. fillagring och det är krypterad överföring även när det sker över lokal LAN.
SSH har också tillräcklig hög säkerhet för att föra över filer på publik internet till en annan server någonstans i världen, man behöver alltså inte gå via VPN som man måste göra om man skall dela ut mappar över SMB och windows nätverksvolymer.
Om man tittar på GUI-backupprogramvaror för backup i windows så kan man säga ungefär - skippa alla som inte kan köra mot SSH i någon av sina lagringsalternativ.
Kan backupprogrammet inte köra mot SSH så är det mycket annat i säkerhet som man också har ignorerat eller inte har insikt på.
Det finns också en fördel till med den kravet med att backupprogrammet skall supporta SSH - Att det är inte är så många backupprogram kvar att välja mellan längre i windows världen och enklare att ta beslut
---
Haken då med Rsync i windows - ja det finns egentligen inge riktig bra rsync-klient för windows och de flesta som finns är i en cygwin-implementation av olika kvalitet och dess värre en del ganska så åldriga och ruttna för att de inte hålls uppdaterade - tex att det inte finns i 64-bits version och kända svagheter i protokoll som Heartbleed är fixade... Det finns också några wrappers med GUI men även dem har cygwin i botten och kan vara rätt ruttna.
Vill man ändå prova så är en väg att gå att man installerar:
https://gitforwindows.org/ - jepp paketet är för att använda GIT i windows och med denna en uppdaterad cygwin eftersom GIT använder sig av en rad Unix-tools bakom skalen för att fungera - i och med att GIT är så stort för att hantera revisioner av programmeringsprojekt (ni känner väl till GITHUB) så hålls även dess cygwin och unix-tools uppdaterad här.
Men av någon anledning finns inte rsync med där och om man följer https://blog.tiger-workshop.com/add-rsync-to-git-bash-for-win... och skrollar en bit ned (har precis kollat det att det fungerar) finns det instruktioner för att få rsync att fungera under GIT-paketets terminal..
Hur man använder rsync är något man får läsa manualer, men en början för att synka mot en SSH-konto någonstans är tex.
'rsync -avPHi /sökväg/till/det/man/vill/göra/backup/på/ -e ssh användarnamn@server:/sökväg/var/backuppen/skall/hamna/ <enter>'
har man inte kört det innan så kommer först en anmodan på att acceptera en certifikat (gör det) därefter en passords-inmatning.
med SSH kan man preparera certifikat för passordslös inloggning och är nödvändigt om man skall scripta rsync och sedan köra det i schemaläggare (cron i unix-världen) för automatik.
När man skall hämta tillbaka filerna så byter man plats på sökvägarna, då dataflödet är data hämtas från vänster sökväg (kan vara fler i rad) och lämnas alltid till sista sökvägen till höger när det gäller sökvägar i kommandoraden.
Oftast har man flaggan '--delete' i kommandoraden för att filer som inte finns på sändarsidan längre också skall tas bort på backupsidan så att filträden blir exakt lika när man kör rsync flertal gånger på samma sökvägar.
För att prova utan att några filer i verkligheten överförs eller raderas så kan man prova först med '--dry-run' i kommandoraden och har man '--delete' så är det högst rekommendabelt första gången innan man vet att det gör som det skall då om man tex. missar en '/' i slutet av sökvägarna vid nästa synkning av samma sökvägar som tidigare så kan det vara vääääldigt många filer som försvinner väääldigt snabbt på lagringssidan.... Det är inga barnskydd på den här typen av mjukvara... och kan bli rätt blodigt om man gör fel...
---
Som lagring av backup på extern USB-disk så använder jag (i linux-miljö) uteslutande BTRFS som filsystem då det är robust mot glappande USB-kablar, av misstag ur-ryckt kraft för disken under full skrivning, USB-kontroller som hänger sig etc. - faktum är att jag provat ganska mycket med olika misshandel och ändå inte fått filsystemet att krascha eller ge felaktig data en enda gång hittills och nu används över 3 år utan incident och det finns ingen anledning att hoppa på tyngre filsystem som ZFS för just den här typen av lagring.
Dessutom ser jag nackdelar att ZFS hantering av kloner och snapshot är hierarkisk med föräldrar-barnberoende av varandra och därmed hela kedjor kan försvinna om man raderar en clon/snapshot nära toppen och inte kan flyttas runt helt fritt som i BTRFS subvolymer helt utan beroenden mellan varandra. - men sådan är upp till var och en att prova och att det fungerar i sin backup-procedur
med BTRFS kan man göra subvolymer komprimerande, man kan man göra snapshot av sin 'master' sökträd som man kör sin rsync emot innan man gör en ny rsync igen. - och snapshot är samma sak som en subvolum i senare hanterande och det finns ingen inneboende hieraki eller beroende av filerna som en gång skapade snaphot/subvolymen - det enda det gör är att det pekar på samma data tills endera av det modifieras och alla modifierinag skrivs då som ny data unikt för filen. det är det som är COW - Copy on Write.
Det gör att det är lätt att skapa datum-versioner av sina backupper utan att det tar mer plats (det är bara tillagda och ändrade filer som växer på disken vid nya synkningar), lätt att klona en subolym av senaste datum och namna om till en ny master ifall man missade på en '/' och fick sin gamla 'master' halvägs raderad innan man upptäckte det... - allt för att inte mer filer än nödvändig skall skrivas på disken.
Att ta bort gamla snapshot/subvolymer är en-sekunds operation kommandomässigt även om filträden är i TB-storlek och filer i miljontal (helt sant är det inte då en lågprioriterad Garbage-collector går igenom den raderade subvolymen och frigör utrymme för filer och fildelar som inte längre finns refererad någon annan stans på volymen.)
