Skrivet av Knetha:
Finns det någon annan Raid-version som täcker backup istället ? (Om jag har samma innehåll i en backup på ena disken som den andra är jag ju också skyddad mot diskras...)
Nej, allt som är 'online' kopplat, räknas som sammankopplad enhet oavsett hur många RAID:ade-diskar, är automatiskt synkat även mot molntjänst (utan sessionshantering, filhistoria eller versionshantering).
dvs. tar du bort en fil - vänta i 6 veckor - kan du på något sätt få tillbaka filen igen på olika vägar (tex NAS, dina datorer, molntjänster) - då kan du kalla att du har någon form av backup - annars inte. Tänk också på om vad som händer om NAS:en blir sönderslagen av åska, elfel internt och grillade diskar eller fel i bakplan som korrumperat all data, fått den stulen mm. - och framförallt den största risken av alla - användarfel... Då är ofta uppdaterad off-line backup på annan plats bra att ha också!.
Filer som du tar bort avsiktligt eller oavsiktligt och sedan via synknings replikerar vidare och sista kopian av filen är försvunnen inom enstaka dygn så är det att betrakta som att du har ingen backup alls. Samma sak kommer att hända vid ransomware att alla dina filer inklusive synkade backupper kommer att ha skrivits över med sin krypterade motsvarighet inom enstaka dygn om du inte har revision/historia eller snapshot-hantering i någon av leden som ransomware inte kan komma åt att modifiera (dvs. filerna är osynliga över nätverk och/eller är skrivskyddade av använda filsystemet själv [som måste ha specialkommandon direkt mot filsystemet för att kunna öppnas för skrivning igen] i fallet när själva NAS:en fått in ransomware som Qsnap råkade ut för ett antal månader sedan via en multimedia-app med gömd bakdörrs-password av apputvecklarna som någon reverse-enginneer:ade och hittade och den vägen fick fulla rättigheter...).
Medans en undanlagt (extern USB) HD utan någon anslutning med kopia på allt vad du har på din NAS så är det att betrakta som en backup då det kan finnas kvar i månader och åratal, tills du ansluter och gör en synkning...
---
lite överkurs:
Nu kan man även på backupdiskar med rätt filsystem (ZFS och BTRFS) göra snapshot innan synkning vilket gör att du har kvar föregående versioner även efter synkning och kan göra så tills disken är nära full och man får ta beslut vad man skall göra med de äldsta snapshoten
Där vinner BTRFS stort då du kan ta bort vilken snapshot som helst i önskad ordning - detta kan man _inte_ göra i ZFS utan skall man bli av med gammal ålderstigen junk (dvs. de första backupperna som gjordes och nu med stor del inaktuella filer) så måste man bygga en ny dataset (på en annan disk då enklast) med senaste sessionen då man inte kan ta bort det äldsta delen i ZFS då alla generationer efter bygger alltid på den första backuppen, precis som en TAR-backup med huvudbackup och sedan inkrement-sessioner efter.
Inkrementsession (läs senaste snapshoten) är inte självbärande i ZFS utan måste ha hela kedjan tillbaka till den första backuppen kvar i alla lägen.
Sedan finns det andra issue med ZFS som gör att det inte är förstavalet med just externa USB-diskar och speciellt inte när de är av SMR-typ (princip alla externa USB-diskar 8TB storlek och mindre) - så i det avseende är BTRFS filsystem som backupdisk-filsystem på externa USB-diskar ett bättre val och är mycket stryktålig mot missöden som urryckt USB-sladd under full skrivande, eller strömavbrott mitt under full skrivande[1]. Man kan få kompression på filsystemet mm. samt att det hanterar SMR-diskar relativt bra och det kan skriva väldigt mycket data innan man slår in i 'väggen' prestandamässigt.
Och ja, det finns dedupliceringsprogram också på blocknivå (bees) att köra på BTRFS och man kan själv bestämma hur mycket RAM-minne man vill lägga ut för jobbet och när man vill köra det till skillnad från ZFS med deduplicering påslaget.
Nöjer man sig med deduplicering på filnivå så kan man använda sig av 'rmlint' som också förstår sig på BTRFS 'clone' eller att använda sig av 'reflink' för att minska diskförbrukning av likadana filer på många olika platser i filträden (bryr sig inte om filnamnet, bara dess innehåll) - vilket kan vara användbart om man möblerat om i filträdet i sin NAS och sedan gjort en backup med rsync eller motsvarande och det tog dubbla utrymmet på backupdisken för att de flyttade filerna inte ligger på samma plats som backupsessionen innan i din tidigare snapshot. Man kan i rmlint med '-C -U' gör att rmlint sparar checksummor och tidsstämpel på var fil som attribut i filsystemet vilket gör att den vid nästa körning inte behöver köra och hasha igenom varenda fil igen när den går igenom disken utan tar bara det som är tillagt och förändrat sedan förra gången.
De flesta synkningsprogram har inte någon insikt när en fil bara flyttas till annan plats i filträdet på tex. en backupdisk - utan konstaterade att en fil försvann på ett ställe i filträdet (och gör motsvarande delete av filen på speglings-avbilden) och sedan hittade en ny fil på en annan plats och filen skrivs in där på speglingsavbilden.
BTRFS har dock ingen inbyggd kryptering men fungerar bra att lägga det ovanpå LUKS-crypt (med cryptsetup) på tex sin backupdisk utan märkbara prestandanedsättnings när det gäller fart mot snurrdiskar.
[1]
NTFS är synnerligen olämpligt val att ha som backup-filsystem på externa USB-diskar - den är för ömtålig och man lätt hamnar i en situation vid strömavbrott eller råka glappa i USB-sladden där windows nästa gång det kopplas in, inte känner igen disken helt plötsligt och det kan vara väldigt jobbig att rädda data ur senare även med kommersiella diskräddarprogram då filerna allt för ofta är söndriga och har bitar med andra filers innehåll i sig...
