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)