Skrivet av Benz0187:
Intressant.
Dock ska det ju lösa mina tidigare problem med att diskarna blir fulla.
Kan man qua att den bara först deletar som filer som saknas, för att sedan kommandot igen för att kopiera?
Manualen för rsync är lång och har många växlar som inte alltid är lätta att bena ut vad de faktiskt gör - bl.a kan man bestämma ordningen hur den nya/uppdaterade filens skrivs - dvs. före eller efter att den nya filen är överförd. - det finns också '--inplace' där man modifierar och byter ut sektorer på en redan befintlig fil - tex uppdatera många hundra GB stor databasfil som annars är jobbig att överföra på nytt var gång och kanske ont om diskplats.
dock --inplace rekommenderas bara om man gör snaphot på sin backup mellan backupomgångarna som i BTRFS eller ZFS.
har man tex hårda länkar så kan det bli rätt sörjigt om sagda fil modifiera från flera olika håll mha... --inplace...
radering av borttagna filer brukar göras först innan det går igenom filträden för att synka upp nya och/eller ändrade filer
Jag bruka köra flagga '-i -i' i kommandot för att se vad som händer och vill man prova med en torrkörning först utan att det gör några åtgärder på disken utan bara simulerar dem så kan man använda sig av '--dry-run' - och det rekommenderas - det hinner raderas väldigt många filer väldigt fort om man råkade missa en '/' sist i en sökväg - därför uppskattas BTRFS (och ZFS) väldigt mycket på sin backuplagring att man också kan göra en snapshot (eller att server/NAS gör snapshot själv på daglig basis, vilket de flesta nyare köpeNAS gör numera) _innan_ man trycker 'enter' för sin ny-snickrade rsync-kommandosekvens...
Skall man jämföra filer på 'binär' nivå (förvisso med hashvärden) så kan man använda flaggan '-c' - men då kommer det ta tid och dessa görs företrädesvis att lagrings-servern har en rsync snurrande lokalt på daemon-nivå (kör man via SSH så startar en sådan automagiskt) så kommer rsync att göras på lagringsservern och räkna igenom sina filer och en rsync på klientdatorn som räknar igenom sina och sedan kommer de att hela tiden skicka checksummor mot varandra på ett smart sätt utan att skicka data mellan sig, men även med detta så måste alla filerna på båda sidorna läsas igenom och är det 50 TB så kommer det ta tid.
Kör man via NFS så kommer det inte köras lokalt utan all data måste köras över nätverket till klienten för jämförelse/beräkning.
kort sagt blir det att läsa manualen för rsync och leta efter olika användarexempel.
Det finns väldigt kraftfulla kommandon som tex. att jämföra 2 olika direktorys och allt som är lika som referensen tas bort på den första och det som skiljer hamnar på en '3:e directory
dock läs noga och prova noga att det fungerar som det skall innan det körs på skarp data - det är lätt att bli blodig om man viftar runt med denna väldigt användbara svärd lite obetänksamt.
- om man inte kör med -c så kan det tex. missa filer där innehållet i filkroppen ändrats men inte filens tidsstämplar som tex. veracrypt-kontainer där man avsiktligt inte ändrar några metadata för filen som indikerar att man har varit inne och rotat i filen, men '-c' är dataflödes och tidsmässigt kostsamt och är inget man vill köra på alla filer i en rutinbackup. Har man sådana kända filer (som veracrypt-kontainrar) så får man göra en rsync-backup specifik för dem med '-c' flaggan.
---
Det finns ytterligare program att kika på när man skall jämföra olika filträn - 'rmlint' - den skapar script som man senare kör och man kan bestämma vad som skall hända med filerna som är lika och hanterar också att jämföra mot master-direktorys som inte får röras i den senare filborttagningen eller deduplikationen gentemot direktorys man vill tömma eller deduplikera filer.
Rmlint bryr sig inte om vare sig filnamn, tidsstämpla eller plats i hierarkin när den jaga dubbletter - medans rsync bygger allt på att sidorna ser lika ut eller gör dom lika och tex upptäcker inte en flyttad fil utan det blir en fil som raderas på ett ställe och skapas igen på annan ställe - vilket det delar med väldig många olika backupprogram och ej har insikt om filer är 'bara' flyttade.
'rmlint' stöder också att för varje fil så sparas hashvärde och tidsstämpel som attribut och skall man tex. tömma snapshot (liggande på subvolymer) i BTRFS så kan jag säga - det spar tid!! - typ från en 24-timmars skörning på en full 8TB disk till 12 minuter...
Dock skall också sägas att man bör köra master och en snapshot av master minst en gång för att få sina hashvärden, då varje ny snapshot som görs av mastern så kommer dessa hashvärden att följa med även i snapshoten - nya filer har ingen hash-värde och ändrade filer så stämmer inte hashvärde mot tidstämpel och filens aktuella datum och då anses som ogiltig hash och filen hashas om.
'rmlint' kan hantera mot BTRFS-filsystem så att den tex. klonar lika data som finns på flera filer även med olika namn (dock inte partiell kloning) medans ZFS saknar i dessa sammanhang en förbaskad viktig funktion som heter '--reflink' (som 'cp --reflink=always fil1 fil2') för att göra oberoende kopia utan att kopiera ny uppsättning datat mellan olika filträn och olika snapshot tvärs över gränser då ZFS snapshot och kloner har hierarki och turordning hur de skapas medans BTFS har inte det.
för filsystem som inte har '--reflink' så finns även hårda länkar (för filer på samma fysiska disk/LVM) och slutligen mjuka länkar för deduplication över olika fysiska diskar/LVM.
