Kör man med hårda länkar med cp -al DIR1 DIR2 när man kopierar backupdirektory så växer det inte så mycket i plats på backupdisken - bara filer som har ändrats så bryter rsync länken i DIR1 (som går emot alla andra tidigare filer som är hårdlänkade till andra kopierade DIR) och det blir en ny fil medans den gamla versionen finns kvar i de äldre backupdirektoryna som DIR2
Ett alternativ att titta på är rsync -avP --delete --link-dest=DIR1 DIR-orginal DIR2
(--delete är viktig om man vill spegla direktoryna, utan denna så raderas inte filerna som ev. finns kvar i DIR2 från en tidigare backup men är borta ur DIR-orginal)
det innebär att från en fil från DIR-orginal/file1 som redan finns på DIR1/file1 från en tidigare backup så läggs det en hårdlänk från DIR1/file1 till DIR2/file1 istället för att göra en ny komplett kopia av filen 'file1' i DIR2 (förutsätter dock att DIR1 och DIR2 är på samma filsystem)
Men skulle det vara någon skillnad på file1 vid backuppen gentemot backuppen tidigare i DIR1 så görs ingen hårdlänk utan file1 blir en ny fil i DIR2 med sitt eget innehåll.
---
rsync har väldigt mycket funktioner och en som jag använder ofta är när jag skall jämföra och tömma snarlika direktorys som tex gamla backupdirektorys, snapshot och hela diskar och vill se vilka filer som har ändrats sig mellan backupper
är rsync vtrP -0 --partial --append-verify --modify-window=2 --links --compare-dest=DIR_compare DIR_source DIR_rest
det innebär att den tittar i DIR_source, jämför med DIR_compare och finns inte filen i DIR_compare eller den är ändrad så läggs en kopia i DIR_rest - annars händer ingenting
Det innebär att alla filer i DIR_Source som _inte_ fins i DIR_compare eller är ändrade, läggs en kopia i DIR_rest.
Ovanstående tittar bara på filtider (modify-time) och "-0" och "--modify-window=2" är till för att hantera konstiga filnamn (i windows) som kan missuppfattas och att tidsupplösning är olika mellan tex. windows-filer och Unix-filer och är det avrundningsfel på nanosekunders-nivå för att de hoppat mellan olika filsystem så anses inte filerna lika fast de är det...
Skall man ha checksummebaserad jämförelse mellan filerna så kan man använda flagga '-c' men då tar det tid - både på servesidan och klientsidan och lastar dessa hårt eftersom filerna måste läsas igenom i sin helt på båda sidorna och utbyta checksummor innan åtgärd görs.
vill man ta bort alla filer i DIR_source efter koll mot DIR_compare (och filer som inte fins i DIR-compare hamnar i DIR_rest) så kan man lägga till "--remove-source_files"
dvs.
rsync vtrP -0 --partial --append-verify --modify-window=2 --links --remove-source-files --compare-dest=DIR_compare DIR_source DIR_rest
och DIR_source töms helt på filer. - rekommenderar dock att man kör utan --remove-source-files först för att se hur mycket det blir i DIR_rest blir innan man låter yxan gå... och även här kan man använda sig av '-c' om man verkligen vill vara säker på att filerna jämförs med checksummor innan delete
Blir det fel så blir det förfärligt många fel i sekunden om det också raderar filer samtidigt...
Skall man jämföra och tömma den ena av 2 nästan identiska diskbackupper på säg 2 TB styck och 8 miljoner filer var så spar ovanstående tid...
---
Att använda hårda länkar för ej ändrade filer i generationsbackuper är inget nytt - så gör tex. apples 'time machine' bakom den snygga grafiska skalet mot användaren.
