Gebruik alleen-toevoegen wanneer een back-upclient minder vertrouwd is dan de repository en er een afzonderlijk vertrouwd onderhoudspad bestaat. In andere gevallen zijn normale toegangsrechten eenvoudiger en transparanter.
Voor een thuisserver die back-ups naar een andere machine verstuurt, draait de echte beslissing niet om de vraag of alleen-toevoegen veiliger klinkt. Het gaat erom of een gecompromitteerde client moet worden verhinderd om oude repositorygegevens vrij te geven, wie het bewaarbeheer mag uitvoeren en hoe herstel werkt wanneer archieven verborgen zijn of voor verwijdering zijn gemarkeerd. Begin met de inloggegevens en het eigenaarschap van het onderhoud en test vervolgens zowel back-up- als herstelgedrag voordat je de repository definitief in een van beide modi gebruikt.
Bepaal welke machine en inloggegevens je niet vertrouwt
Maak een lijst van de bronmachines, de repositoryhost, SSH-sleutels, serviceaccounts en beheerdersidentiteiten. Noteer welke identiteit gewone back-ups uitvoert, welke identiteit het bewaarbeheer uitvoert en welke identiteit kan inloggen op de repositoryhost. Alleen-toevoegen helpt uitsluitend wanneer de minder vertrouwde client daadwerkelijk aan de repositorygrens wordt beperkt.
Een externe back-upserver met alleen-toevoegen is het sterkst wanneer de clientsleutel wordt gedwongen tot een beperkte Borg-opdracht en geen algemene shell of onderhoudsreferentie kan verkrijgen.
Als dezelfde client de beheerderssleutel opslaat, compactie plant en de repositoryconfiguratie kan bewerken, is de geclaimde grens grotendeels procedureel. Als de repositoryhost zelf mogelijk gecompromitteerd is, vormt alleen-toevoegen op die host geen onafhankelijke kopie. Kies de modus pas nadat de dreigingsanalyse laat zien wie van wie is gescheiden.
Controleer wat alleen-toevoegen in je Borg-werkstroom verandert
Maak een kleine tijdelijke repository en voer exact de opdrachten uit die je automatisering zal gebruiken. Voeg twee archieven toe, geef ze weer, pas de geplande bewaarbeheeropdracht toe, probeer compactie uit te voeren met de clientidentiteit en schakel daarna over naar de vertrouwde onderhoudsidentiteit. Leg vast welke gegevens herstelbaar blijven en welke bewerkingen alleen in de huidige weergave van de client worden weerspiegeld.
In een repository met alleen-toevoegen zijn archieven na een verwijderings- of prune-intentie mogelijk niet langer zichtbaar voor de client, ook al wordt de opslag pas vrijgegeven nadat vertrouwd onderhoud dit toestaat. Dat onderscheid moet vóór een incident duidelijk zijn.
De test is alleen geslaagd wanneer de beperkte client back-ups kan maken, beschermde geschiedenis niet permanent kan vrijgeven en de vertrouwde beheerder de transactiestatus kan controleren en het benodigde archief kan herstellen. Als de beheerder niet kan uitleggen hoe een verborgen archief moet worden hersteld, is alleen-toevoegen niet klaar voor productie, ongeacht of het maken van back-ups lukt.
Kies de modus die past bij het eigenaarschap van het onderhoud
Kies alleen-toevoegen wanneer externe of blootgestelde clients back-ups moeten kunnen versturen, een afzonderlijke beschermde identiteit het onderhoud kan uitvoeren, de opslag de vertraging vóór compactie kan opvangen en het herstel is geoefend. Houd deze onderhoudsreferentie weg van gewone back-upclients en gebruik haar uitsluitend vanuit een gehard beheerderspad.
Kies normale toegangsrechten wanneer de repository en de client één vertrouwde beheergrens delen, regulier bewaarbeheer en het vrijgeven van ruimte rechtstreeks moeten worden uitgevoerd en operationele eenvoud belangrijker is dan het beperken van een gecompromitteerde clientsleutel. Een waarschuwing over automatische compactie van repositories met alleen-toevoegen is belangrijk: een geautomatiseerde, vertrouwde compactor kan een door een gecompromitteerde client aangemaakte destructieve intentie voltooien als deze zonder controle wordt uitgevoerd.
Gebruik afzonderlijke repositories wanneer de ene clientgroep vertrouwd is en een andere is blootgesteld, of wanneer hun onderhoudsschema's conflicteren. Verzwak niet elke client tot het minst veilige gedeelde model alleen voor het gemak van deduplicatie. De juiste keuze is afhankelijk van de situatie: alleen-toevoegen beschermt een specifieke grens tussen inloggegevens, terwijl normale toegangsrechten het onderhoud rechtstreeks houden.
Valideer back-up, herstel en onderhoud als één cyclus
Voer de volledige operationele cyclus uit voordat je op de repository vertrouwt. Maak twee back-ups vanaf de client, pas het beoogde bewaarbeleid toe, controleer de resulterende status met de vertrouwde identiteit, herstel een voorbeeldmap naar een afzonderlijke locatie en voer de geplande onderhoudsstap uit. Meet de opslag vóór en na afloop, zodat vertraagde vrijgave zichtbaar wordt.
De toegangsmodus van de repository neemt controles van identiteit en aankoppelpaden niet weg. Als Borg een verplaatste repository niet kan vinden, houd die diagnose van het repositorypad dan gescheiden van het gedrag van alleen-toevoegen.
De modus is geslaagd wanneer geplande back-ups werken, een eerder archief kan worden hersteld, de onderhoudsidentiteit de ruimte bewust kan beoordelen en vrijgeven en dezelfde resultaten na een herstart van de client blijven bestaan. Ga terug naar de testrepository als de zichtbaarheid van archieven verwarrend is, de opslag groeit zonder een veilig onderhoudsvenster of de beheerdersreferentie niet echt afzonderlijk is.
Ondersteuning & Tips
Meer om te lezen

Restic-back-up-, vergeet- en opschoontaken plannen zonder vergrendelingsconflicten
Een compleet Restic-schema voor meerdere hosts dat frequente back-ups, gerichte retentie, fysieke opschoning, controles, nieuwe pogingen en validatie van herstel afzonderlijk behandelt.

Hoe voorkom je dat Restic-opruimtaken geplande back-ups blokkeren
Een preventieplan voor gedeelde Restic-repositories dat back-upvensters scheidt van prune en vergrendeling, nieuwe pogingen en waarschuwingen intact houdt.

Een verouderde Restic-vergrendeling verwijderen zonder een actieve back-up te onderbreken
Een zo min mogelijk ingrijpende Restic-ontgrendelingsworkflow die actieve back-ups beschermt, alleen verouderde status verwijdert en herstel volgens het normale schema bevestigt.

