Kan disksynkronisering orsaka strul på systemdisk?

Kan disksynkronisering orsaka strul på systemdisk?

Har en SSD-disk för programvara och tillfällig arkivering för en del filer. Jobbar mycket med foto och de är snabbare att editera från SSD-disk. Då jag är klar flyttas de (vai Lightroom) till extern disk.

Med mycket originalfoto på diskarna är jag noga med backup. För ändamålet identiska externa hårddiskar och använder mjukvaran 'Create synchronicity' för att uppdatera dem med det senaste bildmaterialet. Fungerar utmärkt. Uppfattar verktyget som att det jämför de båda diskarnas innehåll och sedan förändrar Target-disk så att den reflekterar allt som lagts till (och tagits bort) på Source. I sammanhanget är jag då helt trygg med att INGET kommer förändras på Source.

Då jag även har en del material på SSD-disken (partitionerad C o D) gör jag ibland även backup på den på samma sätt. Har en extern disk för det innehållet som också den är partitionerad. Har kört den rutinen innan men igår hände något.

Vill höra med er om det finns risker med dylik synkronisering med systemdisk och att det kan störa OS på något sätt. Det MESTA har gått bra även denna gång men då jag startade om maskinen idag har OS roddat i min personligen utformade startmeny, som genereras via Win Start-knappen längst ned till vänster (alltså den yta man använder för att skapa programrubriker efter behag och sedan lägga upp shortcuts till programmen).

Efter backupen (det enda jag kan sätta i samband med vad som hänt) har OS reducerat både antal ikoner och rubriker. Vissa är kvar och andra inte. Luckor har skapats där det en gång funnits ikoner.

Jag utgår från att det är gårdagens synkronisering som på något sätt orsakat detta. Synkprogrammet rapporterade ett stort antal filer det inte 'kunde nå' men brydde mig inte nämnvärt eftersom jag antog att det var filer som inte lät sig kopieras och/eller var aktiva genom OS.

Någon som kan ge mer info om detta så jag vet hur jag ska hantera det framöver? Finns väl antagligen en specifik post på systemdisken (Registret?) som håller reda på hur menyn ska se ut. Och antar att det inte finns en backup på den som man skulle kunna återställa allt med? Är ju inget jättejobb att återskapa men högst irriterande...

Att användarprofiler gått sönder har ju hänt förr i windowsvärlden, det är en risk man fått leva med sedan win95 typ... - du har inte haft någon win-uppdatering med tvinganden omstart i samband när du stängde av datorn innan problemet uppstod??

Just detta med påtvingade uppdateringar skulle jag nog säga är en av de större irritationskällorna och hotet mot att ha en fungerande system som på säkert sätt fungerar likadant varenda gång...

Har ingen åsikt om använda synkningsprogram men har den använts länge utan strul och upplevs stabil i funktion så är det nog inte den man skall skylla på först.

Något att titta på är om det finns återställningspunkter i windows (vet inte om det också gäller användarprofiler) - även om jag skulle göra en diskimage av OS-disken innan jag provar att göra en återställning (clonezilla mfl. program som kan göra sådant) - med en diskimage undansparad på någon USB-disk kan man ångra sig om och lägga tillbaka på disken hur det var nu innan man aktiverade återställningspunkten om resultatet efter återställningen inte blev önskade - utan det så är det bara att köpa läget och gå vidare...

Skrivet av xxargs:

Att användarprofiler gått sönder har ju hänt förr i windowsvärlden, det är en risk man fått leva med sedan win95 typ... - du har inte haft någon win-uppdatering med tvinganden omstart i samband när du stängde av datorn innan problemet uppstod??

Nej. Är rätt noga och undviker alltid störningar. Var ingen uppdatering med omstart vare sig igår eller idag.
Och så här långt verkar allt övrigt funka förutom att jag fick en del småstrul med Lightroom (har en stand alone installerad då jag vägrar Adobes 'molntjänster' mot månadsbetalning). Då jag startade upp (startar det programmet flera gånger om dagen) första gången efter min backup reagerade någon dold Adobe Application -programvara strula. Tydligen uppfattade den det som att jag installerat trial, för jag fick åter aktivera det via licensnyckel.

Bara att hålla tummarna och hoppas ingen annan liten 'detalj' i OS-filer o Register fått in något annat som visar sig senare. Dock avstår jag från såväl återställningspunkter (som säkert kommer strula till det med saker jag gjort idag) och en lång procedur med återställning och OS-disk image. Får återskapa mina menyer manuellt om minnet är med mig ;).

Har faktiskt betraktat Win10 som relativt stabilt men har ju varit med sedan Win 3.1 så jag vet vad du talar om. Detta var dock första gången saker hände med profilen.

Låter nog bli att göra synk med systemdisken inblandad framöver. Något har hänt i samband med det och det är ju alltid bra information om man förstått varför - annars får man göra som kungen och vända blad

Om du automatiskt synkar diskar har du överhuvudtaget ingen backup, det är ungefär motsatsen mot den funktion som skyddar dina filer.
Vad händer om nått sker med din "source disk" ? Jo det påverkar din så kallade backup, raderat en fil av misstag ? ja då den borta.
Du bör nog tänka om helt vad gäller backup.

@mrqaffe: Du har missuppfattat något. Vem har sagt 'automatiskt'? Jag gör regelbundet backup på ffa fotodiskarna. Som f.ö. aldrig är kopplade. Backup utförs mha ett sk Synchronioze-program. Då det aktiveras kollar den vad som fn finns på Sourcedisken och sedan vad som skiljer det från föregående backup på Target. Sedan kopierar/raderar det filer efter det. Sedan kopplar jag ur disken igen. Perfekt och säkert. Så länge det inte börjar brinna i huset. Om man ska vara petig

Skrivet av DanMicke:

@mrqaffe: Du har missuppfattat något. Vem har sagt 'automatiskt'? Jag gör regelbundet backup på ffa fotodiskarna. Som f.ö. aldrig är kopplade. Backup utförs mha ett sk Synchronioze-program. Då det aktiveras kollar den vad som fn finns på Sourcedisken och sedan vad som skiljer det från föregående backup på Target. Sedan kopierar/raderar det filer efter det. Sedan kopplar jag ur disken igen. Perfekt och säkert. Så länge det inte börjar brinna i huset. Om man ska vara petig

Kontrollerar du alltid att "source" alltid är korrekt innan du synkroniserar? Att ingen fil av misstag blivit raderad eller korrupt? I så fall är det ju lugnt, men om du i likhet med många andra fotografer har ganska många bilder så har jag en känsla av att du inte kontrollerar allt alltid. I det läget så riskerar du att tappa data med din sk "backup"-metod eftersom du inte automatiskt hanterar revisioner av dina ändrade filer.

Skrivet av mrqaffe:

Om du automatiskt synkar diskar har du överhuvudtaget ingen backup, det är ungefär motsatsen mot den funktion som skyddar dina filer.
Vad händer om nått sker med din "source disk" ? Jo det påverkar din så kallade backup, raderat en fil av misstag ? ja då den borta.
Du bör nog tänka om helt vad gäller backup.

Jag råkade ut för exakt det du skrev. Efter ett strömavbrott var filsystemet skadat. Och massor av filer saknades. Tyvärr märkte jag detta försent när jag körde sync (rsync). Jag såg att hundratals filer snabbt raderades på min "backup-disk"! Som tur är har jag extra backup hemma hos en bekant, så det mesta kunde återskapas.
Numera har jag lagt in en test av filsystemet på "source"-diskarna innan sync körs.

Skrivet av whisky:

Kontrollerar du alltid att "source" alltid är korrekt innan du synkroniserar? Att ingen fil av misstag blivit raderad eller korrupt? I så fall är det ju lugnt, men om du i likhet med många andra fotografer har ganska många bilder så har jag en känsla av att du inte kontrollerar allt alltid. I det läget så riskerar du att tappa data med din sk "backup"-metod eftersom du inte automatiskt hanterar revisioner av dina ändrade filer.

Vet inte vad jag ska kontrollera. Disken är ju bara ansluten i samband med backup. Då denna är klar är disken en kopia av den externa jag har permanent ansluten. Så inga filer kommer vara raderade. Sannolikheten att de bara ska bli korrupta i den hanteringen finner jag rätt obefintlig. Tycker det är ett bra bup-system. Fast visst borde man förvara den andra disken i annan byggnad. Om man ska vara petig.

Skrivet av DanMicke:

Vet inte vad jag ska kontrollera. Disken är ju bara ansluten i samband med backup. Då denna är klar är disken en kopia av den externa jag har permanent ansluten. Så inga filer kommer vara raderade. Sannolikheten att de bara ska bli korrupta i den hanteringen finner jag rätt obefintlig. Tycker det är ett bra bup-system. Fast visst borde man förvara den andra disken i annan byggnad. Om man ska vara petig.

Men om något händer på den permanent anslutna disken, dvs källan, så kommer du tillräcklig kontroll kunna synkronisera över felen till din backup. Det kan vara korrupta filer, raderade bilder eller virusinfekterade filer...
Det jag menar är att om du inte kontrollerar vad som ska synkas över så har du ingen kontroll och då är det ju ingen säkerhetskopia, det är en ren kopia av din arbetsmiljö. Du skapade dessutom den här tråden för att något i din dator blev trasigt, och det finns inget som säger att det inte händer med filer på din bilsamling som alltid är ansluten.

@whisky: Vi lägger nog ner denna diskussionen. Jag har koll på vad jag gör.

Nu görs detta i win-miljö - men i linuxmiljöer och btrfs och göra subvolymer med snapshot är verkligen att äta kakan och ha den kvar.

Tyvärr allt det här roliga gör man i Linux-miljö - inte Windows! så texten efter detta är något OT men kan vara bra att veta vad som finns på andra sidan staketet (= utanför windows-världen)

Först gör man en snaphot mot den volymen man normalt synkar emot på sin externa USB-disk och därmed gör en subvolym (kan göras read-only och det därmed är bök att låsa upp igen för skrivning, ändring och radering) och sedan kör man sin rsync mot den normala volymen för att lägga och ta bort till de filer som skiljer.

På så sätt tål man att klanta sig med tex. argumenten för rsync (tex missa ett '/' i slutet av path) och man ser massor av filer ryka all värdens väg - lugn, din nyss gjorda snapshot har alla dem kvar!.

Strömavbrott och annan bus med USB-kabeln under full skrivning har hittills inte framkallat några filförluster eller gjort volymen icke monterbar (just det som NTFS gör när den absolut inte får, skrämmer skiten ur mig, och jag har provat mycket både avsiktligt och oavsiktligt) - visst det kan ta lite tid i montering efter en sådan event men det hittar alltid ut till accessbar filträd igen. Det man missar vid en strömavbrott mitt under skrivning är max 30 sekunder skrivningar då BTRFS är transaktionshanterande - antingen finns filerna där hela och rena - eller så finns de inte alls, det finns inga mellanting! (ZFS arbetar på samma sätt)

Allt som skrivs på disken ha checksummor datat likväl som metadata ned på atomisk nivå (CRC32C - samma som ISCSI som är bättre för större sektorer med större hammingavstånd än de som används för SATA, Ethernet mfl.som kanalskydd och mycket bättre på att hitta fel än fletcher-checksumma som används i ZFS) och default när man skapar volymen (i linux) på disken så är det dubbel metadata i 'DUP' (ungefär som raid 1 fast på samma disk)

Med andra ord ena metadatan (~= $MFT i NTFS) skiter sig på disken av någon orsak så kan den rädda sig med den andre och rätta upp det hela igen och båda hålls hela tiden synkade vid normal skrivning

BTRFS fungera väldigt mycket bättre på SMR-diskar än NTFS (som är rena öken när det gäller att skriva många små filer på SMR-diskar) och man kommer inte att köra 'huvudet i väggen' prestandamässigt i första taget trots mycket skrivande av småfiler.

Räcker inte disken till - ja det är bara att koppla in en disk till för mer plats i filsystemet (och metadata går från 'dup' till sann RAID1 på två fysiska diskar), är det gott om plats för att frigöra disken - ja då kan man ta bort den igen eller göra till en RAID1 även på datadelen. Finns ingen krav på att diskarna skall ha samma storlek utan kan blandas fritt.

---

Man kan ha olika åsikter angående BTRFS eller ZFS som filsystem på en NAS/SERVER - jag lämnar den frågan därhän.

- men BTRFS är definitivt väldigt bra val för off-line externa USB-backupdiskar där man inte kan vara helt säker på strömförsörjning är stadig till den externa disken eller kan riskerar glapp i USB-sladdarna under sessionerna då det alltid repar sig!! och det här med snapshot med subvolymer gör att man inte behöver vara så nervös om det blir fel eller filer som raderas och oönskat ransomwarekrypterade filer plötligt väller in istället...

BTFS kan idag köra komprimering on the fly medans det skriver/läser men har ingen kryptering - dock ingen svår sak med luksCrypt först på disken innan man skapar BTRFS-filsystemet.

När man väl börjat med snapshot ala subvolymer i BTRFS så är det jättesvårt att vara utan denna igen och tyvärr finns inte samma funktion riktigt i ZFS där man förvisso kan göra snapshot, göra en rollback på önskad snapshot men inte kan hantera en rad snapshot "parallellt" utan beroenden av varandra som i BRTFS då det bokstavligen är som klonade volymer av samma disk helt oberoende av varandra.

Och någon gång måste snapshot rensas - och jag vill i alla fall veta vad det är för filer som skiljer sig mellan snapshoten innan den slutliga slakten då när det är borta så är det borta.

För det använder jag en program som kallas 'rmlint' och jämför snapshot och filträn (där en kan vara 'master' utan att röras) och får skript som tex. kan radera alla lika filer i den ena av de två filträden man jämför snapshot och lämna kvar olikheterna som sedan manuellt kan inspekteras och bedömas om de skall raderas eller inte. - har man fått en förberedande ransoware-angrepp med smygkryptering så kommer det vara många filer kvar och man undrar vad som pågår...

@DanMicke:
Fast nu kanske inte "varför" är det primära här eftersom man då egentligen löser fel problem, utan snarare "att" det har inträffat.

Som man vet är brandkåren väldigt bra på att släcka bränder, men om kan förhindra att en brand uppstår så behöver dom inte komma. Så bästa lösningen är alltså att lösa ett problem från två håll, nog om det. När jag läser dina inlägg så ser dom något spretiga ut och det är svårt att se vad du egentligen gör.

Men om jag gissar lite grand så ser det ut så här för mig (Vilket jag misstänker andra ser det som också):

Du har en originalmapp med bilder - Du synkroniserar den så din "backup" är exakt likadan.
Nästa gång gör du samma sak och du har en exakt likadan backup igen.
Resultatet av detta är att du i princip kör en RAID 1 manuellt.

Problemet här är att du kan använda synkronisering FÖR att göra en backup, inte SOM en backup. Vilket jag tror att många uppfattar att du gör.

För att en synkronisering ska bli en backup så måste man väva in någon form av tidshistorik. En metod här är att använda ett rent backupprogram som har inkrementell backup alternativt att väva in någon form av arkivering med synkroniseringen.

Metoden för detta, som jag själv använder är att synkronisera innehållet till en backupdisk där jag sedan komprimerar backupkatalogen till en tar.gz med ett namn som åååå-mm-dd--tt:mm.tar.gz, vilket gör att jag får tidshistorik, vilket görs direkt efter att synkroniseringen är klar, sedan så synkroniseras backupen mot backupserven.

@xxargs:
Bra inlägg, kan tipsa om detta för backup:

rsync -r -t -p -o -g -v --progress --delete -l -H --numeric-ids -s "/home/" "/mnt/Seagate_10_TB/Backup av hemkatalogen/Aktuell" && tar -cvzf "/mnt/Seagate_10_TB/Backup av hemkatalogen/$(date +%F--%T).tar.gz" "/mnt/Seagate_10_TB/Backup av hemkatalogen/Aktuell"

kommandot ska först köras med sudo su för att få rootkontot och inte enbart sudo, detta för att få rätt ägare på filer, speciellt om man har flera användare.

resultatet av detta är att katalogen Aktuell vid varje tillfälle ser ut som din nuvarande hemkatalog och sedan komprimeras oberoende av varandra.

Om maskinen kraschar under tiden så kan tre scenarion inträffa:
1. Under tiden rsync körs - > börja om från början.
2. rsync är färdigt, men komprimeringsfilen är inte påbörjad. - > börja om från början.
3. rsync är färdigt, men komprimeringsfilen är påbörjad. - > radera tar.gz filen och börja om från början.

Skrivet av OldComputer:

@DanMicke:
Fast nu kanske inte "varför" är det primära här eftersom man då egentligen löser fel problem, utan snarare "att" det har inträffat...

Ok. Är med på vad du säger. Har datorvana sedan Win 3.1 men realtionen till OS är mer vad jag praktiskt behövt sätta mig in i under åren. Du har djupare kunskaper än mig angående det. Uttryckte mig nog lite slarvigt då jag är medveten om att synkprogram kan användas på helt annat sätt. I mitt fall är dock avsikten att jag alltid har backup på större delen av mitt bildarkiv, vars originalfiler ligger på en alltid ansluten extern disk. Jag känner helt enkelt av då en förlust skulle bli smärtsam (t.ex. efter jag editerat ett stort antal bilder) och i de lägena bestämmer jag mig för att skapa en kopia på det som ligger (eller INTE ligger om jag under tiden bestämt mig för att ta bort några bilder för gott på källdisken).

För detta ändamål passar 'Create Synchronicity' (som mitt program heter) förträffligt. Det checkar vad som skiljer sig mellan den nu tillfälligt anslutna (som alltid står helt urkopplad till såväl elnät som dator då jag inte genomför backup) och den permanenta extrena fotodisken. Så det brukar gå rätt snabbt för programmet att föra över den nya filerna, nya editeringar och/eller ta bort filer jag inte längre har kvar på källdisken). Snabbt och smidigt helt enkelt och det är mycket riktigt så att jag ANVÄNDER synkprogrammet för att skapa en backup. Sorry, men uttryckte mig lite slafsigt där.

Då jag som sagt har en partionerad SSD (system o program på en partition och en del arkivfiler på en annan) gör jag emellanåt motsvarande med mina arkivfiler. Denna gång tänkte jag mig inte för utan inkluderade partitionen med OS/Program. Då jag märkte att programmet rapporterade flera filer som 'överhoppade' insåg jag ju direkt hur galet det var att försöka synka mot en disk som hade massa filer öppna och aktiva. Mitt 'varför' var snarast grundat på att jag visste att filer som har med mina personliga inställningar för meny låg på systempartitionen. Vad jag däremot inte riktigt var klar över var hurvida dessa kunde påverkas av att någon software 'sökte av dem' då de samtidigt var öppna? Menar, de borde väl inte sparas om med andra inställningar? Så 'varför' var väl mest för att höra om det fanns anledning att misstänka det i detta fall.

Men jag kan inte se annan anledning till att min meny förändrades än att de faktiskt gjorde det. Så 'varför' gäller väl om ni visste att så kan ske om man 'bara' låte ett program 'söka av' filerna som är öppna. Trodde nämligen inte det.

Men tack för era insikter. Jag gör om min meny manuellt och slutar synka systemdisken

PS. Hitills som sagt bara EN udda sak utöver den ändrade menyn. Lightroom hade 'tappat' informationen (troligen i Regestry) om att jag hade reggat licens och trodde att LR åter var en trial. Hoppas nu att inget annat kraschat som jag inte upptäckt ännu. Kan ni lugna mig?

Senast redigerat 2019-10-10 17:33

Det är nog ingen som kan lova någonting om det har guckat till sig i profilen och registret - och det slog mig att det är kanske en väldigt gammal återställningspunkt som har återladdats för att en uppdatering krachat både profil och registret och det räddat sig till körbar skick med med första friska läsbara återställningspunkten den hittar. Eller att du lyckats starta återställningspunkten av misstag....

windows har ju sådana beteenden att tex. går det inte starta upp OS efter 3 försök (tex. efter en större OS-uppdatering... vilket händer) så gör den rollback med en återställningspunkt till fungerande stadiet innan.

Skrivet av xxargs:

Det är nog ingen som kan lova någonting om det har guckat till sig i profilen och registret - och det slog mig att det är kanske en väldigt gammal återställningspunkt som har återladdats för att en uppdatering krachat både profil och registret och det räddat sig till körbar skick med med första friska läsbara återställningspunkten den hittar. Eller att du lyckats starta återställningspunkten av misstag....

windows har ju sådana beteenden att tex. går det inte starta upp OS efter 3 försök (tex. efter en större OS-uppdatering... vilket händer) så gör den rollback med en återställningspunkt till fungerande stadiet innan.

Vet inte om det är så dramatiskt egentligen. Har ju i godan ro kört datorn utan problem (förutom återaktiveringen av LR o återskapande av min personliga meny) i två dagar. Det mesta har nog varit igång.

Frågan för mig är som tidigare. Skulle den 'avläsning' av disken synkprogrammet gör verkligen kunna påverka filernas innehåll? I princip meddelade bara programmet att det inte 'hittade sökväg' till ett rätt omfattande antal filer. Som att de öppna filerna inte kunde 'hittas'. Inget är liksom korrupt förutom de två nämnda åtgärdsbara detaljerna.

Gissar att ett skadat system säkerligen skulle ge allehanda strul vid det här laget så det är nog lugnt.

Skrivet av OldComputer:

@DanMicke:

@xxargs:
Bra inlägg, kan tipsa om detta för backup:

rsync -r -t -p -o -g -v --progress --delete -l -H --numeric-ids -s "/home/" "/mnt/Seagate_10_TB/Backup av hemkatalogen/Aktuell" && tar -cvzf "/mnt/Seagate_10_TB/Backup av hemkatalogen/$(date +%F--%T).tar.gz" "/mnt/Seagate_10_TB/Backup av hemkatalogen/Aktuell"

kommandot ska först köras med sudo su för att få rootkontot och inte enbart sudo, detta för att få rätt ägare på filer, speciellt om man har flera användare.

resultatet av detta är att katalogen Aktuell vid varje tillfälle ser ut som din nuvarande hemkatalog och sedan komprimeras oberoende av varandra.

Om maskinen kraschar under tiden så kan tre scenarion inträffa:
1. Under tiden rsync körs - > börja om från början.
2. rsync är färdigt, men komprimeringsfilen är inte påbörjad. - > börja om från början.
3. rsync är färdigt, men komprimeringsfilen är påbörjad. - > radera tar.gz filen och börja om från början.

Det är alltid bra med olika tips på backupstrategier med mycket beprövade verktyg som 'rsync' (tyvärr är stödet för rsync inte bra i windows-världen - men att betrakta som standard i Linux-världen då nästan alla backup-gui som synkar filträd mellan varandra - slutar med en gäng flaggor till 'rsync' som gör grovjobbet någonstans bakom dolt)

Dock har jag ogärna komprimerande arkiv (som zip, gzipad tar mfl.) från den tiden jag höll på med bandbackup då minsta fel på arkivet så går inget alls att rädda ur arkivet.

Skall man göra arkiv med komprimering så skall man först gzippa alla filer individuellt som skall in i tar-arkivet och sedan gör man en ej komprimerad tar-arkiv av alla de komprimerade filer. TAR är tålig för skador (läs bandsallat och partiellt saknade stycken) och man kan få ut alla filer runt skadan medans filerna som har delar i skadan är förlorad. Är det zippat eller arkivet komprimerad i efterhand (den normala med flaggan som 'z' i Tar) så gör minsta skada (bitfel) på arkivet oanvändbart för återuppackning efter skadepunkten och med murphys lag så finns skadan alltid precis i början och ju mer sannolikt vid allt mer viktiga filer som lagras i arkivet... (finns dock vissa moder för vissa komprimerare att kunna resynka sig en bit efter skadan, men det är inget allmänt använt)

---

Nedanstående text kanske inte är riktigt OT - och somliga kanske ser att det hamnar i annan tråd, men problemet att göra så tappas sammanhanget med det som skrivs tidigare i tråden - men det är TS som får avgöra...

Det finns en sak till när man jämför snapshot med hela filträd. Med rmlint kan man när man samtidigt jämför filträd - få denna att samtidigt skriva attribut (xattr, finns i btrfs, zfs, xfs, ext4 och några BSD/unixorienterade filsystem till) för varje fil där filens hash och tidsstämpel lagras - gör man det på masterfilträdet och sedan gör snaphot på masterfilträdet inför varje ny synkning så finns xattributen även på snapshot-filerna medans ändrade filer i tex. mastern efter en rsync-körning så stämmer inte tidsstämpeln med hashens tidstämpel och nya filer har ingen attribut alls.

När man sedan skall städa/tömma en snaphot och vill se vad som skiljer mot en nyare version så kan man med rmlint jämföra dess snapshot och rmlint går då på dess hashsummor i filens attribut gjorda tidigare - kollar dess tidstämpel med filens tidsstämpel (mtime) - stämmer det inte så ignoreras hashen och hela filen hashas om igen - stämmer det så nöjer den sig med existerande hashen i senare jämförelse för att se om filerna är lika eller inte.

Två nära identiska snapshot med typiskt tvåhundratusen tidigare hashade filer och volym på kanske 1TB styck var kan då jämföras på mindre än 1 minut totalt (+ tiden för de nya /ändrade filerna som måste hashas om igen) och en raderscript skapas för den snapshot man vill tömma (och de som är unika blir då kvar i snapshoten man vill tömma) - ibland fortare än så om direktoryträdens metadata redan är inlästa i diskcachen av en tidigare sökning.

Det är också en sådan grej som är svår att vara utan när man väl smakat på det...

---

Lite om gången i hur man skapar en BTRFS-volym på en extern USB-disk för backupbruk, gjord på en standard ubuntu desktop installation - man har en tom. säg 8TB extern USB-disk till förfogande, ingen data finns lagrad på den då allt kommer att försvinna!!

Först måste man göra sig av med NTFS på sagda 8TB-disken - när disken i fråga ansluts till ubuntu med USB-sladden så kommer disken att automoteras och bli en enhet - det vill vi inte. Öppna en terminal, för nu kommer kommandona att göras i en shell och man kommer att jobba med root-rättigheter.

Först slår man "sudo lsblk <enter>"

man får lista på vilka lagringenheter som OS:t ser, enhetsbenämning och dess storlek

i listan så finner vi att tex. att 8TB disken har enhetsnamn 'sdc' och en partition utgrenad som "sdc1" som är monterad under /media/disknamn

för att vara säker på att vi avmonterar 8TB disken utan att samtidigt stänga av den och den försvinner som USB-enhet så avmonterar vi inte den via den grafiska desktopens explorer utan i terminal skriver:

"sudo umount /dev/sdc1 <enter>" alternativt "sudo umount /media/disknamn <enter>"

kontrollera sedan med "lsblk" <enter> att "sdc" är fortfarande kvar och att den är 8 TB stor och inte är monterad till någon mapp

Nu har vi med den externa 8TB lagringen lite ambitioner - den här externa disken skall vara krypterad, så att ingen kan snoka i den när den ligger på förvaring mellan backupperna!

så därför bör man börja med att skriva diskens första bit med slumptal

"sudo dd if=/dev/urandom of=/dev/sdc bs=1024k <enter>" ; /dev/sdc är i exemplet din 8TB disk, kolla med "lsblk" igen så att du är _helt_ säker på rätt disk används, fel disk, adjös med datat på den disken, är du ovan med linux - koppla ur alla dina diskar som du har viktig data på innan du startar ubuntu! - skrivningen görs för att få bort alla gammal partitionstabeller mm. och en krypterad disk skall ha menlös info på början så att man inte vet om eller var det finns intressant data eller inte.

När det gått en halv minut eller så - tryck ctrl-C för att bryta skrivningen, det går inte speciellt fort med data från /dev/urandom men tillräckligt mycket i början av disken har ändå skrivits över med slumptal, skall du vänta till disken är fullskriven slump så kommer det ta veckor... vill du disken skall vara fylld med menlös data hela vägen - använd veracrypt och slängnyckel (armbågen i tangentbordet som passord) för att fylla disken med psedoslump, det kommer ändå ta många timmar att skriva 8TB

OK förberedelsen fixad, nu är det dags för cryptsetup

"sudo cryptsetup luksFormat /dev/sdc <enter>"

Detta ger uppmaning att du skall skriva in din passord/passfras - bra passord/passfraser om det skall ha attacktålighet - maskinslumpmässigt framställd minst 12 tecken inom ASCII 33-127 eller 6 ord i passfrasen med skiljetecken mellan orden om den är framslumpad/framkastad med tärningar enligt diceware!

Glöm inte passordet/passfrasen - det finns inga (kända) bakdörrar i sådan här open source-kod, med många ögon som granskar efter svagheter i koden hela tiden, så är passordet/passfrasen glömd så är innehållet i disken förlorad för alltid!. Skriv upp den till en början!.

nu skall vi montera den krypterade disken och görs med:

"sudo cryptsetup luksOpen /dev/sdc C1 <enter>" och mata in passord/passfras för att öppna volymen (du börja tröttna att hela tiden skriva passordet för 'sudo', eller hur - det finns annat sätt men då skriker säkerhetspuristerna om 'dåliga säkerhetsvanor')

med detta har man skapat en virtuell 'öppnad' volym som finns under /dev/mapper/C1 och där är det en rå diskyta (efter avkrypteringen)

För att formatera denna yta med filsystemet BTRFS körs följande

"sudo mkfs.btrfs -L 8TB-backupdisk /dev/mapper/C1 <enter>" (eventuellt kan btrfs-tools behöva laddas ned med 'apt-get' innan)

det tar bara fåtal sekunder

Nu skall vi montera filsystemet till en mapp tillfälligt, och eftersom vi är rätt förtjusta i att backuppfiler komprimeras om det går på backupdisken, helt automagiskt, så börja vi med att skapa en subvolym där all data som läggs i mappen blir komprimerad.

"sudo mount -o compress=zlib /dev/mapper/C1 /mnt <enter>"
"sudo btrfs subvolume create /mnt/compressed_dir"
"sudo chattr +c /mnt/compressed_dir"

nu avmonterar vi disken igen

"sudo umount /mnt"

stänger ned krypteringen i ordnad form (bättre än att bara rycka ur USB-diskskadden för disken rakt av även om det också fungerar i praktiken)

"sudo cryptsetup luksClose /dev/mapper/C1"

ryck ur USB-sladden för disken, vänta 20 sekunder och sätt in USB-sladden för disken igen och låt den varva upp.

Om allt fungerar som det skall i ubuntu desktop så kommer det automatiskt upp en ruta som ber om passordet för disken innan den kan användas vidare.

Med passordet inskrivet så kommer disken sedan finnas under /media/8TB-backupdisk (och som enhet i grafiska miljön) och under denna finns en mapp som heter compressed_dir - allt som läggs i den mappen kommer att komprimeras automatiskt, även stora filträd

dvs. filer som kopieras in med rsync som:

"rsync -aPH -i -i -e ssh användarnamn@datornamn:/path/path2 /media/8TB-backupdisk/compressed_dir/ <enter>"

(mot annan dator med fungerande ssh - vilket i de flesta fallen är unix/linux-burkar)

så kommer man hitta en 'path2/' med filträd under 'compressed_dir som på backupdisken är komprimerad. På typisk systemdisk ala windows kanske filvolymen trycks ihop 30-40% i minskad platsåtgång på backupdisken om det inte är tungt med komprimerade bilder och media samt krypterade filer. Komprimeringen kommer inte att märkas prestandamässigt i praktisk användningen av backupdisken.

OK, nu har man gjort sin backup, och några dagar senare vill man göra ny backup av samma filset till samma path2 i /media/8TB-backupdisk/compressed_dir med samma kommando - utan att förstöra den som redan finns lagrad på disken då vi vill ha en äldre version kvar hur det såg ut för några dagar sedan.

då gör man en snapshot (med eller utan sudo beroende på satta rättigheter)

"btrfs subvolume snap /media/8TB-backupdisk/compressed_dir /media/8TB-backupdisk/compressed_dir_20191010 <enter>"

2 sekunder senare så är det klart och förbrukade extra diskutrymmet är långt under 1 MByte eftersom all lika data pekar på samma fysiska sektorer

/media/8TB-backupdisk/compressed_dir
och
/media/8TB-backupdisk/compressed_dir_20191010

har nu identisk innehåll, men är ändå helt oberoende av varandra som om det vore 2 skilda diskar - se det som en klon av compressed_dir - var och en av subvolymerna kan modifieras eller radera filerna fritt och allt nytt skrivs på nya sektorer utan att påverka sektorer som 'ägs' av de(n) andre subvolymen - det är det som menas med COW

Vill man ha snapshot skrivskyddat så att den inte kan modifieras av elak kod eller klantiga användare, så skriver man:

"btrfs subvolyme snap -r /media/8TB-backupdisk/compressed_dir /media/8TB-backupdisk/compressed_dir_20191010 <enter>"

/media/8TB-backupdisk/compressed_dir_20191010 är fortfarande identisk kopia av /media/8TB-backupdisk/compressed_dir men inget av dess innehåll kan ändras med normala filsystemsmekanismer - att då få den skrivskyddade subvolymen skriv och ändringsbar igen är så komplicerat att jag får surfa på det var gång...

Man kan göra snapshot på vilken subvolym som finns redan - det finns ingen rangordning och man kan ändra namn som vilken mapp som helst och i övrigt beter sig som vilken filträd som helst utom ett undantag - du kan inte ta bort en subvolym med 'rmdir'

utan måste göras med btrfs subvolume delete /media/8TB-backupdisk/compressed_dir_20191010 som exempel och det tar också hela filträdet under denna på typ 1 sekund - mycket snabbt sätt att radera stora mängder filer utan att behöva göra delete på dem en i taget (kan ta tid i normala filsystem) och det är sedan en garbage-collector som går igenom det och tar bort all data som det inte längre finns någon referens till någon annan subvolym eller mapp på disken och den vägen återvinner diskplats.

Nu råkar man kanske klanta sig och skapade en mapp direkt på disken utan att det är en subvolym - då kan man inte göra snapshot på den mappen med filträd under.

Det är rätt lätt att åtgärda - först skapar man en ny subvolym sedan använder man "cp -ar --reflink=always dir_a dir_subvolym"

med 'reflink' så kopierar man filer utan att kopiera - det är bara referenser av filerna som kopieras men pekar på samma data fysiskt på disken och efter operationen kan man ta bort "dir_a" då exakt kopia av filträdet nu finns i dir_subvolym och man kan nu göra snapshot på denna.

med proceduren

Först snapshot med lämplig namn med datum , därefter synka orginaldirektoryt med lämplig program (tex rsync) så kan man skaffa sig en backup med historia/revision och man kan samla på sig typ 50 snapshot på samma disk - det är bara nya och förändrade filer som tar upp ny diskplats (om man är modigt kan man använda --inplace i rsync och då byts bara bitarna som är ändrade i en stor fil (databas) och det är bara dom delarna som ändras som upptar ny plats på disken - inte platsen för hela filen) och alla subvolymer som man gjort tidigare med snapshot på samma fil påverkas inte alls.

När snapshoten är tillräckligt många/gamla och man inte tänker kolla dem innan att ta bort dem så kan man plocka bort dem äldsta en i tagen med "btrfs su delete snapshot_dir' som ovan och det går på enstaka sekund (sedan att disken jobbar en stund efter när GC arbetar är inget man behöver tänka på).

det blev en väldigt lång inlägg och en del OT - men jag hoppas att någon har nytta av det då det ändå tog en stund att skriva, är inte ute efter kasta skit mellan BTRFS/ZFS utan det är efter förtroende vilket filsystem man väljer - för mina krav och flexibiliteten och att den klarar osnygga avslut som glappa kablar utan att göra fel efter riskera att man står med oåtkommlig volym som resultat (som NTFS ibland) som BTRFS har så duger det för min del (och stödet för BTRFS finns i linux-kärnan och allt fler hjälpprogram kring detta som rmlint mfl. använder också mekanismer som kloning och reflink)