Jag tycker att man skall köpa en 4-bay NAS även om man inte fyller upp med diskar det första man gör - dessa är ofta väldigt bra support att kunna stoppa in diskar i efterhand och tillgängliga volymen ökar - direkt eller efter en omstart lite beroende på hur de löser det.
Köper du en 2-bay NAS kommer du att ångra dig med minimal armbågsutrymme att lösa problem som tex. när du har fått en disk som börja visa problem etc. eller behöver mer plats och gå från RAID1 till RAID5.
alternativt som redan skrivits - någon form av dator som du redan har och slänga i en ubuntu headless-server på den och valfri antal diskar
Men också att tänka på en NAS är inte en backup - Backup är en undanställd extern USB-disk som ibland kopplas mot NAS:en och man kör en backup (med tex rsync) och sedan ställs undan igen.
Allt som är online i samma lokal/nätverk är inte backup - en del tycker att molntjänster är en backup, men även detta är tveksamt om inte molntjänsten har session eller generationsbaserad lagring där du kan backa bandet en eller flera steg och få fatt på en äldre backupsession när du fått dina två senaste automatiska backupper uppsynkade med ransomwarekrypterade filer som har krypterats på din NAS och sedan synkats mot molntjänst automatiskt och du inte upptäcker detta förrän flera dagar senare.
---
Har din NAS/server stöd för BTRFS som filsystem, så rekommenderar jag att skapa BTRFS som filsystem på din undanlagda USB-disk (med dubbel metadata!!) då är det enkelt att göra en skrivskyddad snapshot innan nästa backup (med rsync) och du får den vägen generationsbackupper som inte tar extra plats utom det som ändrats lagts till eller flyttats runt.
BTRFS på extern USB-disk är extremt tålig mot missöden som uryckta USB-sladdar under full skrivning, strömavbrott mm. och filsystemet är _alltid_ monterbar igen efteråt - möjligen kan man ha tappat de sista 30 sekunders skrivningar - det är inte som med NTFS där windows säger att den inte känner igen disken vid en gång av 100 anslutningar och du måste köra diskräddningsprogram för att få ut mer eller mindre trasiga filer ur din backupdisk - jag har själv provat det.... och litar_inte_ på NTFS som filsystem på externa USB-diskar sedan dess!!! Dessutom fungerar NTFS dåligt på externa USB-diskar med SMR-teknik när man skrivit 15-30 GB med småfiler (vilket gäller de flesta på 8TB storlek och alla under 8TB storlek från alla tillverkare) medans det fungerar mycket bra med BTRFS medans ext4 är ett mellanläge.
En snapshot av en mappträd kan bara göras på speciellt skapade subvolymer - dvs gör man mapp med 'mkdir' så fungerar det inte.
skapa en subvolym gör man med:
btrfs su create /media/användare/backupdisken/master_filträd
en snapshot på ovan skapade subvolym görs typiskt med:
"btrfs su snap -r /media/användare/backupdisken/master_filträd /media/användare/backupdisken/snapshot_av_master_filträd_datum <enter>"
ett par sekunder är det klart och inget kan ändras i din snapshot med standard filhanteringsoperationer från OS och det tar heller ingen extra plats på disken.
Med tex. programmet 'rmlint' (som skapar ett script som du kan granska innan du kör det senare) kan man deduplicera på filnivå i efterhand med 'clone' (långsamt) eller 'reflink' (snabbare) om du tex. flyttat ett helt filträd till annan plats i filträdet i NAS:en och den vägen få tillbaka den extrautrymmet det tog i senaste backuppen på din backupdisk och filerna i denna generation kopplas istället tillbaka till identiska datakroppar som finns i de tidigare snapshoten i backuppen och platsen återvinns utan att det syns efteråt i den senaste backupen
- rmlint kan mycket mer som att jämföra 2 filträd/snapshot där den ena är master och den andre som skall tömmas - tillverka ett skript som tömmer den mappen som skall tömmas och de filer som inte fanns någon kopia på i mastern lämnas kvar i mappen som tömdes och du efteråt kan bedöma om filerna skall raderas eller flyttas.
rmlint med -U och -C som option sparar hashvärdena (blake2) och tidsstämpel för varje fil som gås igenom som attribut, vilket gör att vid nästa jämförelse mellan tex. 2 snapshot så går det väldigt fort då det bara jämför på hashvärde och att tidstämpeln stämmer med filens tidsstämpel (och därmed inte ändrats sedan förra gången) och därmed antar att det är lika och gör ett skript som tar bort ena mappens filer när scriptet senare körs.
Dessa filattribut kopieras när man gör snapshot, så kör man mot master tillräckligt ofta så hålls även mastern uppdaterad och dess attribut följer med vidare på snapshot som görs av mastern.
en rmlint-kommado som tömmer en mapp/snapshot för filer som finns i master_map kan liknas:
"rmlint -o sh:rmlint01.sh -C -U -T "df, bl, ed, ef" -g -r -m -k /sökväg/till/mapp/som/skall/tömmas // sökväg/till/mapp/som/är/master/inget_i_denna_raderas"
Sch som sagt, första sökvägen jämförs med den andra sökvägen efter '//' som då är 'master' (jämförs på binärnivå - ej på namnnivå) och som skapar ett script rmlint01.sh. När den körs, skapar den en scriptfil som raderar allt i mapparna i första sökvägen som har en eller flera kopior i den andra sökvägens mappar, samtidigt skapar hashvärden som lagras som attribut för var fil som finns kopia på i de båda mapparna och kör man senare en gång till på en snapshot av mastern och en uppdaterard av ny backup master (med tex. rsync) så kan jämförelsen gå på mindre än 1 minut fast det är miljon filer och flera TB med data att jämföra.
Dock måste man ta bort skrivskyddet på den snapshot som skall jämföras för att få sina attribut uppdaterade och senare raderas av den skapade scriptet
