Permalänk
Medlem

NAS?

Funderar på att skaffa en NAS till alla mina bilder (CR2/NEF) så jag har nån slags backup för dem, men då är frågan vad ska man satsa på.

Har sneglat på att göra egen av en Synology DS218 och 2 x Seagate IronWolf NAS 8TB diskar, eller om man ska köpa en färdig NAS från Western Digital.

Alternativ 1:
https://www.webhallen.com/se/product/280022-Synology-DiskStat...
https://www.webhallen.com/se/product/312089-Seagate-Ironwolf-... x2

Alternativ 2:
https://www.webhallen.com/se/product/314970-WD-My-Cloud-EX2-U...

Har tyvärr inte råd med en 4-bay enhet och 4 diskar, dock har jag fått rekommendationer om bra "cloud"-tjänster för billig peng och jädrans massa utrymme.

Vad säger ni?

Permalänk
Medlem

Fick en gammal stationär dator på jobbet med 2xxx i5a, satte i en HDD och senare en till, istället för CD-läsaren. Kör Linux på burken. Vet inte om det är intressant, men är ett rätt bra budget-alternativ. Man kan ju ofta komma över ett chassi med sakerna, sedan trycka i egna diskar. Har tidigare kollat på NAS, men det enda jag kom fram till var att man betalar en del för hårdvara som inte känns det minsta relevant.

Ledsen om det kanske inte var ett rakt svar på din fråga, men är ju ett bra billigt alternativ om inget annat

Permalänk
Medlem

Egen NAS vs Cloud tjänst

Egen NAS blir ju att man får pilla själv och även stå för att byta ut diskar om de strular
Cloud tjänst blir ju lättare men kanske dyrare i längden (vet inte vad priset ligger på). Sen är jag skeptisk till vad dom använder datan /bilder man lägger upp på den tjänsten

Själv har jag en egen burk med 6 diskar och Unraid som jag skulle rekommendera om man gillar att pilla själv

Permalänk
Medlem

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