NAS - Vad ska man gå för?

Permalänk
Medlem

nja, RAID5 är inte gammal - utan handlar mer om hur många diskar du har i RAID-setet - RAID5 kan man ha för 3-5 diskar typ.

RAID6 konkurerar klart med en RAID10-lösning om man bara har 4-bay NAS, medans är det 6 och flera diskar så är RAID6 klart att föredra.

Sedan skall man ändå ha regelbunden backup på en NAS på ett eller annan sätt.

En NAS med Raid-lösning är inte en Backup - Backup har man först när samma data finns på minst 2 oberoende lagringsenheter (NAS räknas som 1 enhet oavsett antalet diskar och RAID-filosofier inuti sig)

Permalänk
Permalänk
Inaktiv
Skrivet av Mr IKEA:

@da-li: Haha tror du förstår mig bra här >.<

Känns som om jag blir bara mer o mer förvirrad ju mer info jag får just nu.

@Mr IKEA:
Jag försökte växla in diskussionen på ett enklare spår igen, men det är inte alltid så lätt här ...

Jag tycker att du ska börja med att fundera på följande saker:
* Vad har du för totalbudget? En sjyst NAS med minst fyra diskplatser kostar troligen mellan fyra- och femtusen. Sedan behöver du diskar till NAS:en plus backupdiskar och dessa kostar tillsammans minst dubbelt så mycket som NAS:en. Du kommer att landa på en summa som motsvarar en helt ok dator.
* Fundera över vilket totalt utrymme du vill ha i din NAS eftersom det nog är enklast att köpa alla diskar till NAS:en i samma storlek. Du kan börja lite försiktigt med två diskar i NAS:en (men då får du inte den säkerhet som RAID 5 eller RAID 6 ger; om du vill köra RAID 6 bör du nog dessutom köpa en NAS med minst fem diskplatser) och två (jo, två) externa backupdiskar.
* Börja med backupdiskarna eftersom de är bra att ha även innan du köper en NAS. Hur mycket data har du och hur snabbt växer de? Måste du ha säkerhetskopior på dina gaminginspelningar eller räcker det med digitalkamerabilderna? Fundera på hur stora backupdiskar du behöver ha (ta i ordentligt och tänk på att varje backupdisk bör rymma ALLT – även om ett par år) och börja hålla koll så att du kan köpa diskar om du hittar några bra erbjudanden. Köp inte backupdiskarna samtidigt (det är inte ovanligt att en viss tillverkningsserie (batch) drabbas av fel och då kan båda diskarna krascha) och köp helst två lika stora diskar av olika märken (jo, du bör vara paranoid för att få så hög säkerhet som möjligt ...). Du bör dessutom bara ha en backupdisk åt gången ansluten till NAS:en och växla mellan dem ganska ofta.

När du vet svaren på frågorna ovan börjar du med att köpa backupdiskarna.
Sedan börjar du leta efter en NAS som passar dig och köper hårddiskar till den.

Om du fotograferar mycket bör du förstås också rensa bort de bilder som inte är användbara så snabbt som möjligt. Du kan spara mycket plats genom att göra det.

Permalänk
Medlem

Fundera lite extra på exakt varför du behöver RAID. Som sagts redan så är RAID ingen ersättning för backup. RAID är bra om man behöver hög tillgänglighet och är kunnig/villig nog för att fixa problem. Du behöver bra backup mer än du behöver RAID!

Om du har en RAID med fyra mindre diskar så är sannolikheten för problem fyra gånger större än om du har en enda stor disk. Grovt uppskattat. För vissa typer av problem och RAID kan data på NAS fortfarande gå att komma åt. För andra typer av fel är all data på alla diskar förlorad direkt, och måste återställas från backup. Medan du reparerar RAID kan ytterligare en eller flera HDD haverera, möjligen med total förlust av all data.

För de behov du beskrivit, om det är korrekt, räcker det fint med en liten pigg ARM NAS, exempelvis Odroid HC2 med en rejält stor fin NAS HDD.

Du kan till och med ha två stycken, en som normalt NAS och en bara för backup över GbE. Då har du även redundant hårdvara, om något skulle hända.

Satsa på bra diskar avsedda för NAS med 3 eller 5 års garanti. Skulle något hända med en disk så får du en helt ny på garantin. Köp nya (större?) diskar innan/när garantin går ut. Använd de gamla för sekundär offline backup och arkivering.

Visa signatur

Linux och Android

Permalänk
Medlem

RAID ska man aldrig använda som privatperson, det är en teknik för att öka tillgängligheten av inkritiska system. ZFS och deras RAIDZ därimot handlar om redundans, en vital komponent i säkerställandet av lagringen av data över tid. Hårdvara går sönder och då måste du ha en mekanism för att hantera det. Backup är inte tillräckligt eftersom du kan backa upp trasig data (egen erfarenhet). Om du som privatperson har digital information du tänker dig spara längre än 3-5 år finns det nog idag inga alternativ till OpenZFS eller ZFSOnLinux.

Skickades från m.sweclockers.com

Permalänk
Inaktiv

@Mr IKEA
Hur har det gått?

Permalänk
Medlem

@anon36896:

Budget är ingen fara för mig just nu tack o lov. Men jag känner ändå inte för att spendera 10 000 kr på en NAS om du förstår vad jag menar. Allt jag tänkte lagra på den är bilder och videos. Skulle det gå lost e det ju inte hela världen men det e klart att det är skittråkigt när man byggt upp ett bibliotek.

Jag köpte en till extern hårddisk då jag inte blev något klockare av tråden o kände att jag var tvungen att läsa på om detta och sedan läsa tråden igen för att förstå typ Men jag blir liksom bara mer o mer förvirrad för varje nytt svar jag läser känns det som just nu.

Permalänk
Medlem

Jag kör en 2 slot Synology NAS som har några år på nacken, kör ingen RAID setup alls utan kör en ren kopia på andra disken som syncas en gång per dygn. Behöver inte återbygga någon RAID eller liknande om något händer med ena disken.

Tycker inte en 2 slot är något problem, hade tidigare 2 st 4 TB diskar i den och när det började bli fullt efter ett antal år var det billigt nog med 8 TB diskar för att byta ut dem. När dessa blir fulla sätter jag väl i 12 TB diskar.

Permalänk
Medlem

Att köpa en till USB externdisk och sedan göra (regelbunden) backup på innehållet i sin NAS är absolut den viktigaste förbättringen - att sedan gräla om ext4/BTRFS/ZFS och i detta RAID1-6 form och dess motsvarigheter i BTRFS/ZFS är mer en akademisk och filosofisk fråga - och helt ointressant den dagen åskan har gått igenom NAS:en och det enda som är kvar är det som lagrades i backupdisken (och förvaras elektriskt sett urkopplad mellan backupsessionerna)...

Lagring på molntjänster för off-site lagring är förvisso också en bra grej, men börja bli kostsamt när det börja vara mer än enstaka TB i diskvolym och har man 'fri lagringsmängd' hos någon ställe så inskränkts det förr eller senare och det är trist och kanske inte hinner flytta detta i tid till annan tjänst innan de nya avtalen börja gälla.

- Glöm inte hur Crashplan hanterade det hela och det var väldigt mycket data som förlorades då de som inte ville konvertera sina konton till en betydligt dyrare lösning hann inte ta hem sina data inom de relativt korta tidsfristen av anledningen att väldigt många försökte göra det samtidigt och takten låg på 1-2 siffriga byte/s och skulle ta åratal för att hämta hem säg 1 TB data.

Med andra ord - använd molntjänster för bekvämligheten och som offline-backupp - men se till att också ha en kopia på allt på egen backup hemma också så att du kan säga upp en tjänst och öppna en annan när du känner att villkoren är bättre för den nya och utan att försöka tömma den gamla tjänsten för att fylla upp den nya... ...istället ladda upp till nya tjänsten från sin lokala kopia.

Permalänk
Medlem

Dagen då du ska återskapa data från backup efter att åskan slagit ner å du upptäcker att en stor del är korrumperat för att du inte användt ZFS (egen erfarenhet) så är det inte en speciellt filosofisk fråga längre..

Skickades från m.sweclockers.com

Permalänk
Medlem

@xxargs: Jo tack, sedan runt ett år tillbaka sitter jag med 20 TB i limbo efter att min Netgear RN204 med 8x2+6x2 TB blev dödad när en hantverkare bröt strömmen trots att han blev tillsagd jävligt uttryckligen att han skulle säga till innan om han ens behövde göra det.
Mycket riktigt är det BTRFS, MDADM och RAID 5 på den. Har kört en jävla massa recovery-verktyg och fått fram sådär 2 TB av det som fanns.

Nån gång får jag väl skrammla ihop 50-60 papp och skicka till IBAS...

Visa signatur

11600K@5.1 GHz + 32GB Corsair Vengeance RGB PRO 3200@3400 MHz + MSI RTX 2080 Super Gaming X Trio +
WDC Blue SN550 1TB + Black OEM SN730 500GB + Kingston A1000 480GB + A2000 500GB + NV2 1TB + 2TB R10 + RGB most of THE THINGS! + Corsair 4000D Airflow + 2*ZyXEL NSA326 2*3TB @ R1 + Netgear RN2100 4*3TB @ R10 + RN204 4*4TB @ R5 + Synology DS216j 2*4TB @ SHR R1 + DS418 4*8TB @ SHR R6
| tmp: R5 3600@4.2 GHz + 32GB 2666@3066MHz + 1060 6GB@2100/4500MHz + 1 TB NV2 & 512GB SN730

Permalänk
Medlem

@ZaInT: Ouch, jäkligt tråkigt.
Det är för sånt man bör ha en UPS till sin NAS.

Permalänk
Medlem

@Garmzon Menar du silent korruption (dvs omärkligt korrupta filer som kopieras) eller att filerna inte går att läsa alls i ditt fall, eller rent av att filsystemet som sådan inte går att läsa ?

Hårddiskar gör sällan korrupta sektorer av sig själv utan istället genererar IO-error när datat inte är läsbart av någon orsak - inte heller att de ger en 'massa korrupta data', bara en mer eller mindre mängd IO-error pga. oläsbar data - om det är läsbar men korrupt data så är det ditskrivet tidigare av programmet/filsystemet som skrivit datat till disken.

felrättningen är mycket stark i SSD och snurrdiskar och en miss-korrigerad sektor eller felaktig sektor som går igenom oupptäckt är extremt sällsynt - typ minst 100000 mer sällsynt är att du får en oläsbar sektor. Dataskyddet som går igenom SATA-kabeln är betydligt klenare än hårddiskens egna skydd då det bara skyddas av en 32-bit CRC-summa per 512-byte och enligt T10 räknar man med ca 4.5 oupptäckta fel per år när man läser kontinuerligt 500 MB/s per Sata-länk dygnet runt.

Dock - har du lagrat data på SD-minnen eller USB-stickor, så gäller dessvärre inte ovanstående resonemang utan det kan ge silent error i massor...

----

@ZaInT

Vilken topologi hade du på diskarna - i avseende de olika diskstorlekarna, du skrev RAID5, men...

Med 2 8:or och 2 6:or så kanske man partitionerat 8:orna som 6TB-partitioner tillsamman med 6TB-diskarna blir en RAID5 och de kvarvarande 2TB på 8:orna används inte - eller ?

Det finns dock ett problem med arrangemanget med 4st 6TB partitioner i RAID5 och det blir 18 TB synligt plats tillsammans - du vill inte ha filsystem över 16 TB på en 32-bitars system som sagda Netgear RN204.

Detta gäller i stort sett alla NAS med 32-bitars OS (läs i stort sett alla med ARM-processorer) att de inte kan hantera filsystem med storlek över 16TB även om filsystemen som sådan klarar mycket mer. och detta gäller både ext4 och BTRFS och kör man större filsystem än 16TB bara för att det gick att formatera för det så kommer det jättesurt när man fyller disken och passerar 16TB-gränsen - går filsystemet till read-only (dvs du kan inte längre skriva filer på NAS:en - gör backup på rubb och stubb igen - varenda fil på Nasen _utan_ att stänga av NAS:en - för starta du om Nasen nästa gång så är filsystemet förlorad för alltid !!! Varning alltså!!!

Problemet är att många av dom här systemen har inga spärrar för detta när man skapar filsystemen eller varnar för det då det inte för så länge sedan var drömnivå att kunna skapa filsystem över 16 TB när största diskarna låg på 4 TB...

---

Gissar att det är MDADM som krachat vilket tyvärr kan hända och filsystemet ovanpå är då helt utlämnad åt MDADM.
MDADM kan teoretisk göras mer resilient mot plötsliga avbrott då det finns en betaversion för journalskrivning (lite som "slog" i zfs) - men plats måste reserveras i samband med skapandet av RAID och det är dyrt prestandamässigt så därför är det inte påslaget av de flesta distributionerna default eller ens ger möjligheter till detta - men om någon frågar mig så är Gigabitethernet flaskhalsen i en NAS och bandbredden till diskarna för en journal bör inte vara ett problem, så varför är det inte påslaget kan man fråga sig?

Kan du få ihop mdadm-raiden (i Read Only!) så att imagen av BTRFS är läsbar i någon kombination av diskarna i degraded mode i mdadm ? - man bör få till den virtuella enheten att man kommer åt den liggande BTRFS-imagen i ett stycke sas. - i värsta fallet läsa ut till annan media...

Sedan skulle jag prova att montera btrfs-imagen i readonly eller RW på en _kopia_ av imagen (inte i NAS:en utan på en riktig dator/laptop med en modern distribution och uppdaterad BTRFS och btrfs-tools i denna), skulle inte alls bli förvånad om efter en stunds skrotande faktiskt får upp ett fullt fungerande filsystem - min erfarenhet är att BTRFS är förbaskat stryktålig och det värsta som kan hända är att du tappat senaste 30 sekundens transaktion då den rullat tillbaka till en tidigare om den sista inte kunnat slutföras.

Sedan om ovanstående inte skulle fungera finns det en off-line filräddningsverktyg i btrfs-tools kedjan som när jag provade för ett par år sedan på en avsiktlig sabbad BTRFS där jag fick ut det mesta av datat (utom det som skrevs sönder förstås) - det tar helvetes tid och man bör få med alla flaggor som man anser nödvändiga för tex tidsstämplar och behörighet redan från början när man startar räddningsverktyget då det är efter lång tid lite snopet att man fick tillbaka filerna, filhierakin, men alla med 'dagens' datum - men ut kom filerna till slut och med filhireakin i behåll - mer än vad man kan säga om de olika kommersiella NTFS-filräddningsprogrammen kan åstadkomma när $MFT är skadad/borta... Nu är det inte säkert att korruptionen av filsystemet pga. strömavbrott är samma typ som jag provade med. Men kanske värt ett prov...

En sak som man bör gå in och göra preventivt och när man skapar sina (BTRFS) volymer i sin köpenas - även i värsta fallet manuellt via SSH om/när GUI inte tillåter det - se till att BTRFS har DUP (vid '1-disk' som filsystem liggande på en MDADM-RAID) / RAID1 (vid flerdisk där BTRFS själv rår om diskarna) på sin metadata påslaget - det ökar överlevnadschansen mångfald vid plötlig avbrott då sannolikheten är mindre att hinna skriva sönder två olika metadata på två olika fysiska ställen samtidigt när strömmen försvinner...

För konvertering av en BTRFS liggande på en MDADM kan man tex. använda "btrfs fi balance start -mconvert=dup /mountpunkt" för detta när man konverterar metadata till DUP i SSH-promten och överliggande systemet kommer inte att veta om det i senare användning utan det bara sker...

Permalänk
Medlem

Hur funkar det när man lägger till en ny disk i en NAS, får man bara mer utrymme på en gång eller måste man formatera om hela skiten?

Permalänk
Medlem

@Chromatic

Beroende vilket RAID-mode man valt... men oftast utökas det automagiskt, ibland kan det efter att nya disken är instoppad och systemet upptäcker det, för att konverteringen skall starta så krävs också omstart (det beror på att det möblerar om i partitionstabellerna på diskarna och dessa behöver läsas in på nytt)

Dock på en 32-bitars ARM baserad NAS (dvs de som är billigare i pris) - ha aldrig partitioner större än 16 TB per logisk volym och det beror på att det är begränsning för att det är 32-bitars OS och inte 64-bitars OS och då man fyller upp en stor logisk volym över 16 TB så kan det bli jättetråkiga konsekvenser och oftast med resultatet att man förlorar hela volymen med alla filer i sig - Detta visar sig oftast med början att volymen går i Read only-mode (dvs inte kan skriva filer till Nas:en mer - bara läsa) - starta _INTE_ om NAS:en i det läget, utan gör backup på alla filer istället (om dessa inte kom ifrån en backup redan) - för nästa gång du startar om NAS:en är volymen med stor sannolikhet helt förlorad.

Skall man vara säker på att inte köra huvudet i sådana saker - se till att NAS:en har en 64-bit Intel-processor eller att den garanterat går på 64-bitars OS, men då är prislappen i regel högre... - kanske nördiga detaljer att hålla reda på men så är det, och du vill inte förlora filer - eller hur!

Permalänk
Medlem

Felkorrigering spelar ingen roll om datat du backar upp redan är korrumperat. Att säga att hårddiskar sällan korrumperar sig själv är en klen tröst den dagen du har förstörd data. Om man dessutom använt ZFS i några år så börjar man få en känsla för hårddiskars pålitlighet, något som gemene man enbart ser som behovet av att ominstallera Windows med några års mellanrum.

Skickades från m.sweclockers.com

Permalänk
Medlem

@Mr IKEA:

Open media vault, särskilt om du har gamla PC delar liggande. Är superenkelt idag med så goda guider som t.ex "Techno dad life"

Visa signatur

Fractal Design Define R6, ASUS X99a, Xeon E5-2697v3@3.5Ghz allcore, 64gb Hynix ECC REG 2133Mhz, ASUS 1070GTX, 2.5gb nic

Server: Proxmox med OMV 5 och annat virtuellt: Supermicro X9SRH-7F, 64gb RAM, Xeon 2651v2, 4x10tb, 2.5gb Nic

Permalänk
Medlem

Jag instämmer med OMV. Jag kör OMV på sex NAS just nu. Små pigga 8-kärniga ARM32-baserade NAS med 12TB Ironwolf hårddiskar. Odroid HC2. De får fint plats på ett halvt hyllplan i en Billy-bokhylla från IKEA. Blir ca 1 W per TB vid full drift. Tillsammans med en switch blinkar de fräckt kvällstid. Lite som en instrumentpanel i ett rymdskepp från en SF-film från förra århundradet.

"Bzzzt. <click>This is Mission Control! Do you read me? Over!<click>"

Ingen RAID, men hälften används för daglig backup i flera versioner med rsync.

Visa signatur

Linux och Android

Permalänk
Medlem

Är inte btrfs lika bra som zfs för långtidslagring? Vad exakt skiljer där emellan för båda är väl "självhelande"?

Visa signatur

Citera för svar!

Permalänk
Medlem

ZFS är en mogen produkt med en klanderfri historia, BTRFS har haft tekniska problem och är övergiven av tunga organisationer så som Red Hat. ZFSOnLinux verkar vara påväg att bli industristandard då jag hört att FreeBSD överväger att byta från OpenZFS. Men det är endel features från OpenZFS som måste komma på plats först så som SSD trim.

Skickades från m.sweclockers.com

Permalänk
Medlem

Snapraid vs zfs förutom högre hårdvarukrav för zfs. Erfarenheter?

Visa signatur

Fractal Design Define R6, ASUS X99a, Xeon E5-2697v3@3.5Ghz allcore, 64gb Hynix ECC REG 2133Mhz, ASUS 1070GTX, 2.5gb nic

Server: Proxmox med OMV 5 och annat virtuellt: Supermicro X9SRH-7F, 64gb RAM, Xeon 2651v2, 4x10tb, 2.5gb Nic

Permalänk
Medlem

Det är två helt olika saker, om allt du vill är att ett gäng filer är uppbackade så fungerar snapraid antar jag, men ZFS är ett filsystem och fördelarna med ZFS är således inte begränsade till enskilda mappar. Snapshots, kompression och datasets är fördelar som enskilt gör ZFS överlägset något som snapraid.

Skickades från m.sweclockers.com

Permalänk
Medlem

För att ett filsystem skall vara "självhelande" krävs kontrollsummor och redundant data. Dessutom vill man naturligtvis ha säkerhetskopia, gärna i flera versioner.

Detta innebär det enklaste självhelande system man kan skapa har 4x lagringsbehov.

Dubbla diskar för data med btrfs eller zfs med självhelande konfiguration. Dubbla diskar för säkerhetskopia med btrfs eller zfs med självhelande konfiguration.

Tyvärr finns det idag (vad jag vet, rätta mig gärna) inget system som gör att man kan utnyttja redundansen i säkerhetskopian för att skapa ett självhelande system bestående av två noder med nätverksuppkoppling till varandra. Det skulle då innebära att man bara behöver 2x lagring med data+säkerhetskopia+kontrollsummor för att ha självhelande data och säkerhetskopia. Det verkar som ett självklart tillägg till zfs och btrfs för att kunna utnyttja möjligheterna med dessa filsystem fullt ut automatiskt på ett ekonomiskt försvarbart sätt. Märkligt att det inte(?) finns ännu!

Skickades från m.sweclockers.com

Visa signatur

Linux och Android

Permalänk
Medlem

ZFS RAIDZ2 med 8 diskar är självhelande med enbart 1,33x lagring

Skickades från m.sweclockers.com

Permalänk
Medlem

Hjälper inte om hela Nasen förloras vid tex. åsknedslag i närheten, men vill man exportera 'diskar' över nätverk så kanske man kika lite på iSCSI - inte helt ovanligt att SAN-lagring presenterar sin lagring på så sätt.

Permalänk
Medlem

För vanliga dödliga är det dubbla lagringsplatser som gäller, ZFS i båda ändarna och kontinuerlig sync med förslagsvis ZFS Send/Receive

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Garmzon:

ZFS RAIDZ2 med 8 diskar är självhelande med enbart 1,33x lagring

Och sedan behöver du ha lika bra eller bättre backup dessutom. Och då är du uppe i 16 diskar, 2 servrar och 2,67x lagringsbehov.

Jag föredrar att inte använda RAID alls. Bara backup. Men ett smidigt system med checksummor som använder backup-kopian för att fixa bitrot vore väldigt trevligt. Men vad jag vet går det inte att lösa automatiskt. Man får jobba med kontrollsummor och flytta filer mer eller mindre manuellt. Det borde gå fint att automatisera genom ett tilläggsprogram till ZFS eller BTRFS, men vad jag vet existerar det inte. Ännu.

Visa signatur

Linux och Android

Permalänk
Medlem

Backup kan vara en enda disk med ZFS, inte självhelande men åtminstone inte felagnostiskt.

Filbaserad hashning är inte samma sak som ett redundant filsystem med checksums på blocknivå.

Blocknivåkomprimering tar hem en inte oväsentlig andel av lagringskvoten.

Skickades från m.sweclockers.com

Permalänk
Medlem

Beroende på vad för data - men blockkomprimering ger idag mindre platsbesparing än man hoppas på och det beror på hur datat ser ut idag - idag är väldigt mycket komprimerat redan från början - många dokument och arkivformat är zip:at per default redan av använda programmen, även binärer i många fall mer eller mindre stora bitar i sig som är i zip:ad form.

Mediafiler av olika slag är till natur svårkomprimerade och annan 'content' kan vara krypterade vilket heller inte ger någon plastbesparande vid kompression.

Förr räknade man med typ 50%, idag kanske det ger 10%-15% i platsbesparing. - det som däremot ibland kan skotta fram mycket plats är deduplicering - redan på filnivå kan det vara mycket platsbesparande och med deduplicering på blocknivå ytterligare lite till (men inte så mycket som man hoppas på)

Har man filsystem som kan hantera hårda länkar, (de flesta 'unix'-filsystem inklusive NTFS kan hantera det) och btrfs 'clon' så kan man använda 'rmlint' för att leta reda på filerna som till binär är identiska och sedan få alla dessa att peka på samma binär fast filnamnen är på olika delar av filträdet genom att köra det resulterande scriptet - alltså en filmässig deduplicering.

Både med BTRFS (med hjälp program) och ZFS kan deduplicera på blocknivå men är en sysselsättning som behöver (väldigt) mycket RAM-minne, lastar diskarna hårt under tiden och tar sin tid att genomföra. Där får man ställa frågan om blockvis deduplicering är värt extra mödan i jämförelse med tex. deduplicering på filnivå - och på den frågan skulle jag säga att i de flesta fallen 'nej' deduplicering på filnivå ger ofta mycket nog och i de flesta fallen betydligt mer plats än enbart komprimerande filsystem i platsvinst.

---

Ett backup/arkiveringsprogram som både komprimerar och deduplicerar i väldigt fina delar är borg-backup. Att prova att göra en backup på tänkta diskinnehållet som en borgbackup på annan extern USB-disk (du behöver väl ändå ha backup ??) så får man indikation på hur mycket mindre plats det kan ta och jämför hur mycket av disken som är allokerad och om skillnaden är så stor att det löna sig mödan!.

Borgbackup kan hantera multipla generationer backup/arkiv och från olika källor och man kan ta bort vilken backupgeneration som helst oberoende av varandra.

Jag har tex. alla mina diskimages tagna under åren i en borgbackup - förvisso nu över 3TB stor men skulle man packa upp alla diskimages som finns där från massor av olika datorer mm. så skulle det bli över 34 TB stort.

Permalänk
Medlem

min server komprimerar ubuntu vm zvol's med i snitt 1.45x, jails för native FreeBSD tjänster i snitt 1.40x, loggfiler ligger på strax under 6x, databaser run 1.10x och övrig data så som dokument komprimerar i snitt 1.10x

Så om du har en RAIDZ2 pool a 8 diskar käkar blockkomprimering upp en ansenlig del av 1.33x lagringskvo