Btrfs är ett bra val som filsystem på en lagringsdisk - men den kan du göra snapshot av subvolymer, tex inför varje ny backup-session eller på daglig basis med 'cron-script' - och snapshot tar ingen extra diskplats när den genereras - dvs. även om innehållet ändras på orginalmappen så ändras inget i gjorda snapshot av mappen ifråga, och tvärt om. - men ändringarna tar upp ny diskplats så länge den gamla datat finns refererat kvar på någon av filerna.
En subvolym ser ut som en filmapp men är som en filmapp med en monterad (i det här fallet en virtuell inom BTRFS) disk - det går alltså inte ha hårda länkar mellan 2 subvolymer men i övrigt är det som vilken mappstruktur som helst.
Detta är en hemligheten bakom att kunna göra snapshot då att göra en snapshot så gör man kopia på dess 'virtuella' disk med metadata och inod-listor på plats och ingen i metadatat behöver räknas om eller kopieras - det enda som skapas nytt är en startpunkt på några få kilobyte i metadatat. - även roten på BTRFS går att göra snapshot på och innehållet har en kopia på allt som tillhör roten i den skapade subvolymen - dock inte innehållet i mapparna som är subvolymer utan visas då som tomma mappar. Man kan också i samband med mount montera en av subvolymerna som roten av BTRFS och det som var 'rooten' nu blir en subvolym istället.
Det fina med BTRFS är att snapshot och subvolymer har ingen inbördes hieraki (till skillnad från ZFS) mer än numeriskt för identifikation utan kan tas bort oberoende av varandra i skapandeordning och data som tappat och som inte längre har någon referens till någon av subvolymerna blir då ledig diskplats igen
Det går också få automatisk kompression på allt som läggs under en mapp i BTRFS.
---
Om man förutsätter att din disk med BTRFS-filsystem ligger monterad under /Backup
Skapa en subvolym i BTRFS:
sudo btrfs su create /Backup/backuppmapp_orginal
att sätta att all data som läggs i backupvolym_orginal komprimeras automatiskt.
sudo chattr +c /Backup/backupmapp_orginal
Med detta så komprimeras allt som läggs i mappen 'backupmapp_orginal' och alla mappar som skapas under denna automatiskt och default arbetar heuristiskt - dvs. den komprimerar filen om det lönar sig och enligt metoden att den provar att komprimera en liten bit i början av filen och går det inte med någon platsbesparande så skippar den att försöka komprimera resten av filen vilket tex. gäller mediafiler för att inte i onödan belasta CPU med kompressions-jobb som ändå är bortkastat. För filer som är komprimeringsbara så jobbar den också smart och komprimerar bara de delar som är komprimerbara och delar som inte går att komprimera med någon vinst läggs okomprimerat direkt på lagringen (för att inte få overhead-data för kompressionen som också tar plats) och detta sker inflätat inom samma fil.
För att göra en snapshot på en subvolym (vilket bara tar någon sekund)
sudo btrfs su snap /Backup/backupmapp_orginal /Backup/backupmapp_snapshot_1
med detta får du en på byten lika identisk kopia av din /Backup/backupmapp_orginal i /Backup/backupmapp_snapshot_1
De delar all data och även metadata till samma sektorer på hårddisken och det tar ingen extra diskplats - men mapparna är ändå _helt_ oberoende av varandra och man modifieras oberoende av varandra och ändringarna tar ny diskplats - det är filsystemets COW-egenskaper (COW = Copy on Write) som gör att detta är möjligt.
En subvolym skapad av en snapshot av en annan subvolym är inte 'värd mindre' än orginalet utan _är_ samma som orginalet,
'snapshot' är själva momentet att skapa en förfylld subvolym med kopia av redan befintlig subvolym och är inte någon 'egen' dataformat som bara duger för att göra 'rollback' eller motsvarande. 'rollback' som används i ZFS finns inte som begrepp i BTRFS, men kan göra en sådan funktion med hjälp av subvolymer om man vill - men då utan att förlora datat på den versionen som man vill göra rollback ifrån och ha den kvar för senare analys.
Man kan göra en ny snapshot på en volym som är gjord med snapshot obegränsat. Eller ersätta orginal-mappen som blivit mess av tex. en ransomware med en subvolym av en snapshot gjort dagen innan angreppet med att bara byta namn på mappen till dess orginal mappnamn och tex. att samba som delar ut share tittar i denna istället (ev. att samba startas om en gång precis efter mappnamnsbytet för att släppa gamla filhandles och skapa nya på de korrekta filerna istället).
Vill man göra snapshoten till skrivskyddad version (ej modifierbar snapshot) så använder man:
sudo btrfs su snap -r /Backup/backupmapp_orginal /Backup/backupmapp_snapshot_1_RO
där "-r" instruerar att skapad mapp skall vara skrivskyddad.
Subvolymen som skapas då kan du inte ändra något alls i - inte ens flytta denna och varenda byte på mappen själv och under mappen är nu fryst - inget ändras i den även om du försöker, inga tidstämplar och fildatum kan ändras, ej heller rättigheter eller namna om filer - det är djupfryst på riktigt. Det gör också när man tittar i mappen att inga tidsstämplar för läsning av filen ändras heller. tekniken som BTRFS har för att 'frysa' en subvolym är att nyttja att BTRFS alltid behöver nya, lediga sektorer för att kunna modifiera data och metadata och genom att sätta att subvolymen har 0 byte ledig diskutrymme i subvolymen så kan den inte göra något alls.
En ransomware kan inget göra med denna med de sedvanliga POSIX-filoperations-kommandona.
Men givetvis går det att göra en subvolymmapp i Read-only till att bli skrivbar igen med:
sudo btrfs property set -ts /Backup/backupmapp_snapshot_1_RO ro false
Men kräver att man är sudoer/root för att göra momentet.
Har man fått en ransomware som eskalerat sig till 'root'-rättigheter i en Linux så är det kört ändå, men har inte ransomware-mjukvaran kunskap om BTRFS-kommandon så kan dessa snapshot/subvolymer i RO-mode klara sig även om alla andra filer blir uppkrypterade.
---
BTRFS har mycket mer finesser som att kunna addera till diskar efter hand när de blir fulla (och bli JBOD/RAID0) - ha dubbel metadata som på en enda disk är i 'DUP', vid 2 fysiska diskar och fler delas upp på flera diskar för att garantera att minst 2 upplagor av metadatat ligger på minst varsina fysiska disk - att ändra RAID-mode när man önskar som att ändra från JBOD till RAID1 om tillräckligt med ledig diskplats finns för det och 'RAID1' kan göras på fler än 2 diskar och udda antal diskar då BTRFS RAID1 är inte en sektorspeglings-raid utan ser till att samma fil finns i 2 exemplar på 2 fysik olika diskar i alla lägen. och allt görs givetvis online medans disken arbetar med sin tex. backuproll.
Det finns RAID5/6 i BTRFS också och även om det inte rekommenderas så har inte jag haft några problem med detta trots flera års drift och med havererade diskar i denna - eller om man vill, jag har haft mer bekymmer med mdadm-RAID med korrupta filer... men jag har aldrig förlorat filer i en BTRFS RAID5/6 ännu.
Program som 'bees' kan göra en bakgrunds-deduplikation av hela BTRFS på blocknivå medans man använder filsystemet och även när man skriver och ändrar filer samtidigt - dock en varning, då filerna dedupliceras dynamiskt i olika blockstorlekar ned till sektornivå (dock 4k block som minst) så kan läshastigheten gå ned ordentligt för att många av filens sektorer har upptäckts vara lika andra filers sektorer på annan plats och reallokerats vilket gör att det kan jaga runt ordentligt på diskytan för att få ihop filen igen vid läsning - jag har provat att kört bees under en längre tid på arkiveringsdiskar med BTRFS som filsystem då man onekligen spar en del diskyta (mycket mer än tex. att använda diskkompression) och hittills har den inte gjort fel eller skapat korruption på filsystemet. bees har fördelen gentemot ZFS deduplicering att du själv kan styra hur mycket RAM-minne du vill allokera för dedupliceringen - och ju mindre med RAM, ju större blir minsta dedupliceringsblocken - vilket kanske inte alltid är en nackdel om man inte vill ha sina filer allt för fint deduplicerade i små block och då längre återläsningstid.
'bees' görs också 'sparse' för filer med mer eller mindre stora regioner med sektorer som är fyllda med bara '0' - vilket gör att det kan spara mycket diskyta för tex. diskimages tagna från datorer med SSD (där OS gör trim på alla raderade filer och 'optimize' på filsystemet 1 ggr veckan som win10, vilket gör att det mesta av den lediga utrymmet på filsystemet är 'nollad' och bara läser ut '0' som data på sektorerna) - det ger lite mer besparing än att lägga diskimages på komprimerande mappar då även sektorer där med bara '0' kan inte bli mindre än 4 kByte per 128 Kbyte block som är kompressionsindelningen för BTRFS komprimerade sekvenser i filsystemet.
Dock i filsystemet syns inte filerna som 'sparse' fast filerna med stora nollade avsnitt inte tar upp någon diskplats.
Detta med att stora filer kan gå trögt att läsa ut ser man också på andra deduplicerande arkiv och backupprogram (som borgbackup, restic mfl.) då filerna inte längre är sekventiellt skrivna utan kan hoppa runt ordentligt i letande av småbitar i filsystemet när det skall sättas ihop till sekventiell fil igen vid utläsning)
Skall man deduplicera på filnivå så är det bättre att använda 'rmlint' och stöder också faciliteter som att klona filer eller göra 'reflink' på dessa så att olika filer på olika ställen eller filnamn med identisk innehåll pekar på en och samma fysiska binär men inte är hårdlänkat utan fortfarande oberoende av varandra och ha sina egna tidsstämplar i behåll och kan modifieras fritt utan att någon annan fil påverkas.
