Det arkitektoniska målet är sunt: använd RAID 0-SSD:er endast för den arbetsbelastning som verkligen behöver maximal genomströmning, skydda sedan den högriskbaserade arbetslagringen med oberoende HDD-säkerhetskopior och behåll minst en kopia på annan plats. RAID 0 har ingen redundans, så ett enda SSD-fel kan göra hela arbetsarrayen otillgänglig.
I community-svaret från 2025 rekommenderades fristående roterande HDD:er tillsammans med rsync varje natt, men den ursprungliga skribenten framförde en viktig invändning: ZimaOS hade redan ett Auto-läge i Backup, och de ville veta om en äldre HDD som sattes tillbaka i samma fack skulle identifieras automatiskt. Tråden avslutades innan frågorna besvarades. IceWhales aktuella dokumentation ger nu en tydligare stödd grundnivå: Backup-appen stöder schemalagda uppgifter, flera oberoende destinationer, återupptagning och feltålighet samt versionshanterade återställningspunkter – men den aktuella offentliga dokumentationen beskriver inte något garanterat arbetsflöde där man kan ”byta in vilken gammal HDD som helst i samma fack och automatiskt stämma av den utifrån dess identitet”.
RAID 0 behöver en riktig säkerhetskopieringsplan
RAID 0 kombinerar SSD:er för kapacitet och prestanda utan paritet eller spegling. Ett fel på en enda medlem kan förstöra arrayen. För professionellt arbete bör säkerhetskopieringen ses som en del av designen, inte som något som läggs till senare.
Fristående säkerhetskopierings-HDD:er lämpar sig bättre för rotation än RAID 1
Communityn rekommenderade att hålla varje 26 TB-HDD fristående i stället för att para ihop två av dem i RAID 1. Då blir varje disk en komplett, flyttbar kopia som kan förvaras på annan plats, och man slipper bygga om en spegling varje gång en disk roteras.
Detta är en designrekommendation från communityn, inte ett krav från IceWhale. RAID 1 kan förbättra tillgängligheten så länge båda HDD:erna är installerade, men är mindre praktiskt som fysisk rotations- och offsite-lösning.
Aktuella ZimaOS Backup stöder det centrala 3-2-1-arbetsflödet
IceWhales aktuella dokumentation säger att en enda Backup-app kan använda Zima-, USB-, LAN- eller molnkällor och destinationer, köra uppgifter enligt schema, återuppta avbrutna överföringar, behålla versioner och återställningspunkter samt hantera flera uppgifter från en källa till olika destinationer.
Använd den aktuella Backup-modellen i ZimaOS.
Lås dig inte vid etiketten från 2025: ”Auto betyder omedelbart vid varje ändring”
Den ursprungliga skribenten citerade ett gränssnittsmeddelande som sade att Zima-/USB-källor kunde köras omedelbart när filer ändrades. En annan officiell community-diskussion från samma period beskrev däremot ZimaOS Backup Auto som något som körs vid specifika tidpunkter, vanligtvis tidigt på morgonen. Källan själv försonade aldrig dessa beskrivningar.
Den aktuella offentliga dokumentationen beskriver schemalagd säkerhetskopiering och lovar inte filsystemshändelsebaserad replikering efter varje ändring. Vid produktionsplanering bör du använda det aktuella dokumenterade schemat i stället för att förlita dig på en gammal formulering i gränssnittet.
rsync är ett speglings- och överföringsverktyg, inte automatiskt en versionshanterad säkerhetskopiering
Community-skriptet använde:
rsync -avh --delete ...Flaggan --delete gör att destinationen speglar borttagningar från RAID 0-källan. Det kan vara användbart för en spegling, men det kan också vidarebefordra oavsiktliga borttagningar till säkerhetskopieringsdisken.
Om rsync används bör du börja utan destruktiva flaggor, använda --dry-run, verifiera målsökvägen och utforma ögonblicksbilder eller versionshantering separat om återställning efter borttagningar är viktigt.
Diskrotation kräver stabil identifiering och uttrycklig verifiering
Att byta diskar i ett och samma fysiska fack garanterar inte att varje disk som sätts i alltid får samma monteringsnamn eller sökväg. En robust rotationsprocess bör identifiera disken med en stabil enhets- eller lagringsidentitet, bekräfta att det förväntade målet är monterat och därefter starta säkerhetskopieringen.
Kör inte ett destruktivt speglingsjobb enbart för att ”något” är monterat på den gamla målsökvägen.
Rotera kopior på annan plats oftare än varannan eller var tredje månad för kritiskt arbete
En rotation var tredje eller fjärde månad lämnar ett stort glapp i återställningspunkterna om både den lokala arbetslagringen och den lokala säkerhetskopian går förlorade samtidigt. Lämpligt intervall beror på ändringstakt och verksamhetens tolerans, men viktiga professionella data motiverar vanligtvis en tätare rotation till annan plats.
Testa återställning innan du litar på rotationen
Återställ ett representativt projekt eller en representativ fil från varje säkerhetskopierings-HDD, verifiera kontrollsummor eller att filen kan läsas av programmet och notera datumet för den senaste lyckade säkerhetskopieringen innan disken tas ur drift och flyttas till en annan plats.
Vanliga frågor om säkerhetskopiering av RAID 0
Är RAID 1 på säkerhetskopierings-HDD:erna samma sak som att rotera oberoende säkerhetskopior?
Nej. RAID 1 förbättrar tillgängligheten så länge båda diskarna ingår i speglingen, medan oberoende diskar är enklare att ta bort och förvara på annan plats som separata kopior.
Lovar den aktuella ZimaOS-dokumentationen verklig replikering i realtid vid varje ändring?
Den aktuella offentliga Backup-dokumentationen beskriver schemalagda uppgifter, återupptagning och feltålighet samt versioner, snarare än en garanterad filsystemshändelsebaserad spegling.
Är rsync --delete automatiskt säkrare än ZimaOS Backup?
Nej. Det speglar avsiktligt borttagningar och kräver noggrann validering av målet samt separat versionshantering om du vill kunna återställa efter misstag.
