Ska ett Borg-arkiv använda läget Endast tillägg eller normal åtkomst?
Använd append-only när en backupklient är mindre betrodd än arkivet och det finns en separat betrodd underhållsväg. I annat fall är normal åtkomst enklare och mer transparent.
För en hemmaserver som skickar säkerhetskopior till en annan maskin är den verkliga frågan inte om append-only låter säkrare. Frågan är om en komprometterad klient måste hindras från att återta gammal arkivdata, vem som får köra underhåll av lagringsregler, och hur återställningen ska fungera om arkiv döljs eller markeras för borttagning. Börja med autentiseringsuppgifter och ansvar för underhåll, och testa sedan både säkerhetskopiering och återställning innan du bestämmer vilket läge arkivet ska använda.
Definiera vilken maskin och autentiseringsuppgift du inte litar på
Lista källmaskiner, arkivvärd, SSH-nycklar, tjänstekonton och administratörsidentiteter. Markera vilken identitet som utför vanliga säkerhetskopieringar, vilken som utför underhåll av lagringsregler och vilken som kan logga in på arkivvärden. Append-only hjälper bara när den mindre betrodda klienten faktiskt begränsas vid arkivets gräns.
En fjärrbaserad append-only-backupserver är säkrast när klientnyckeln tvingas använda ett begränsat Borg-kommando och inte kan få ett allmänt skal eller underhållsbehörighet.
Om samma klient lagrar administratörsnyckeln, schemalägger komprimering och kan redigera arkivkonfigurationen är den påstådda gränsen främst procedurbaserad. Om själva arkivvärden kan vara komprometterad är append-only på den värden inte en oberoende kopia. Välj läge först när hotbilden visar vem som är separerad från vem.
Verifiera vad append-only ändrar i ditt Borg-arbetsflöde
Skapa ett litet arkiv som kan tas bort efter testet och kör exakt de kommandon som din automatisering ska använda. Lägg till två arkiv, lista dem, tillämpa det planerade kommandot för lagringsregler, försök komprimera med klientidentiteten och byt sedan till den betrodda underhållsidentiteten. Dokumentera vilka data som fortfarande kan återställas och vilka åtgärder som bara återspeglas i klientens aktuella vy.
I ett append-only-arkiv kan arkiv sluta visas för klienten efter en borttagning eller en avsikt att rensa, trots att lagringsutrymme inte frigörs förrän betrott underhåll tillåter det. Den skillnaden måste vara förstådd innan en incident inträffar.
Testet är godkänt först när den begränsade klienten kan skapa säkerhetskopior, inte permanent kan återta skyddad historik och den betrodda administratören kan granska transaktionstillståndet och återställa det behövda arkivet. Om operatören inte kan förklara hur ett dolt arkiv återställs är append-only inte redo för produktion, oavsett om säkerhetskopieringen fungerar.
Välj det läge som passar ansvaret för underhåll
Välj append-only när fjärranslutna eller exponerade klienter behöver skicka säkerhetskopior, en separat skyddad identitet kan utföra underhåll, lagringen klarar fördröjningen före komprimering och återställning har övats. Förvara underhållsbehörigheten separat från de vanliga backupklienterna och använd den endast från en härdad administratörsväg.
Välj normal åtkomst när arkiv och klient delar samma betrodda administrativa gräns, rutinmässig rensning och frigöring av utrymme måste köras direkt och driftsenkelhet är viktigare än att begränsa en komprometterad klientnyckel. En varning om automatisk komprimering av append-only-arkiv är viktig: en automatiserad betrodd komprimerare kan slutföra en destruktiv avsikt som skapats av en komprometterad klient om den körs utan granskning.
Använd separata arkiv när en klientgrupp är betrodd och en annan exponerad, eller när deras underhållsscheman krockar. Försvaga inte alla klienter till den minst säkra gemensamma modellen för att förenkla deduplicering. Rätt val är villkorat: append-only skyddar en specifik gräns för autentiseringsuppgifter, medan normal åtkomst håller underhållet direkt.
Validera säkerhetskopiering, återställning och underhåll som en helhet
Kör hela driftscykeln innan du förlitar dig på arkivet. Skapa två säkerhetskopior från klienten, tillämpa den avsedda lagringspolicyn, granska det resulterande tillståndet med den betrodda identiteten, återställ en exempel katalog till en separat plats och utför det planerade underhållssteget. Mät lagringsutrymmet före och efter så att fördröjd frigöring blir synlig.
Åtkomstläget för arkivet ersätter inte kontroller av identitet och monteringspunkt. Om Borg inte hittar ett flyttat arkiv ska du hålla den felsökningen av arkivsökvägen separat från append-only-beteendet.
Läget är godkänt när schemalagda säkerhetskopior fungerar, ett tidigare arkiv kan återställas, underhållsidentiteten kan granska och frigöra utrymme medvetet och samma resultat kvarstår efter en omstart av klienten. Gå tillbaka till testarkivet om arkivens synlighet är förvirrande, lagringen växer utan ett säkert underhållsfönster eller administratörsbehörigheten inte verkligen är separat.
Rekommenderade produkter
Support och tips
Mer att läsa
Så schemalägger du Restic-jobb för säkerhetskopiering, borttagning och rensning utan låskonflikter
Ett komplett Restic-schema för flera värdar som separerar frekventa säkerhetskopieringar, avgränsad lagringstid, fysisk rensning, kontroller, omförsök och validering av återställningar.
Så förhindrar du att Restic-rensningsjobb blockerar schemalagda säkerhetskopieringar
En förebyggande plan för delade Restic-arkiv som separerar säkerhetskopieringsfönster från rensning och behåller låsning, nya försök och aviseringar intakta.
Så här rensar du ett inaktuellt Restic-lås utan att avbryta en aktiv säkerhetskopiering
Ett så lite ingripande Restic-upplåsningsarbetsflöde som möjligt, som skyddar aktiva säkerhetskopieringar, endast tar bort inaktuellt tillstånd och bekräftar återställningen enligt det normala schemat.
