Restic-back-up-, vergeet- en opschoontaken plannen zonder vergrendelingsconflicten

Plan back-ups regelmatig, voer forget uit via één repositorycontroller en voer prune minder vaak uit binnen een exclusief onderhoudsvenster. Laat niet elke host alle drie de taken uitvoeren.

Een gedeelde home-serverrepository heeft twee soorten timing nodig: herstelpunten per host en repositorybreed onderhoud. Stel het schema op basis van gemeten looptijden en hersteldoelen op, niet aan de hand van vaste internetvoorbeelden. Centraliseer retentie en prune, groepeer snapshots correct, leg de volgorde van units expliciet vast en geef elke overgeslagen taak een nieuwe poging en een waarschuwing. Het schema is pas compleet nadat twee cycli en een voorbeeldherstel hebben aangetoond dat retentie en vergrendeling werken zoals bedoeld.

Inventariseer elke taak, eigenaar en slechtste normale looptijd

Maak één tabel voor elke bewerking die de repository aanraakt: back-up, forget, prune, check, unlock, snapshotlijst en hersteltest. Noteer de initiërende host, opdracht of wrapper, inloggegevens, normale en slechtste recente looptijd, time-out, regel voor nieuwe pogingen en bestemming van waarschuwingen. Neem ook taken op die verborgen zitten in back-uptoepassingen of NAS-interfaces.

Een gedeelde repository heeft repositorybreed onderhoud nodig in plaats van één kopie per client. Praktische Restic-praktijk voor meerdere hosts wijst forget, prune en check één keer per repository toe, waarbij retentie wordt gegroepeerd voor de relevante hosts en paden.

Breng dubbele onderhoudstaken onder bij één controller. Behoud het eigenaarschap van back-ups per host wanneer dat de toegang tot de bron vergemakkelijkt, maar laat elke host de start- en eindstatus aan de controller melden. Als een taak geen gemeten looptijd of eigenaar heeft, observeer deze dan voordat je er een onderhoudsvenster omheen plant.

Stel eerst de back-upfrequentie in en bepaal daarna de reikwijdte van forget

Kies de back-upfrequentie van elke host op basis van de hoeveelheid wijzigingen die je maximaal kunt verliezen en de normale duur van een back-up. Verspreid grote bronscans in de tijd als ze concurreren om netwerk- of opslagcapaciteit, maar spreid taken niet alleen om een schema er netjes uit te laten zien. Laat de langste normale back-up het vroegste begin van het onderhoud bepalen.

Voer forget uit vanuit de repositorycontroller en bekijk vooraf welke selectie wordt gemaakt met de beoogde host-, pad- en taggroepering. Een onverwachte agendagroepering kan ervoor zorgen dat retentie meer herstelpunten verwijdert dan een eenvoudige interpretatie van de bewaaraantallen doet vermoeden.

Houd forget en fysieke prune bij het ontwerpen van het schema logisch gescheiden. Het vooraf bekeken retentiebeleid kan na een geslaagde back-up worden uitgevoerd of in een eigen controllerfase, terwijl prune een langer exclusief venster krijgt. Koppel prune niet aan de back-up van elke host alleen omdat één opdracht beide kan combineren.

Plan prune en check in repositorybrede vensters

Voer prune minder vaak uit dan back-ups en doorgaans ook minder vaak dan forget, omdat fysieke opschoning van de repository veel langer kan duren en ander werk blokkeert. Plan deze taak nadat alle verwachte back-ups en retentieselecties zijn voltooid. Geef check een eigen fase of venster, afhankelijk van de omvang van de repository en de snelheid van de backend.

Een systemd-configuratie voor Restic kan back-up en pruning in afzonderlijke services houden, zodat de planner hun afsluitstatussen kan waarnemen in plaats van één ondoorzichtige opdracht te starten.

Als prune regelmatig het venster overschrijdt, laat back-ups dan niet stilzwijgend opstapelen. Verlaag de frequentie van prune, verruim het venster, onderzoek de backenddoorvoer of splits repositories wanneer hun operationele behoeften niet langer bij elkaar passen. Toegang vereist dat er geen actieve back-up is; afsluiten vereist een schone onderhoudsstatus en een vrijgegeven repositoryvergrendeling.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Leg afhankelijkheden, nieuwe pogingen en waarschuwingen vast

Leg de gewenste volgorde vast in plaats van te vertrouwen op tijdsverschillen: back-upunits melden hun voltooiing, forget wordt pas uitgevoerd nadat de vereiste back-ups zijn afgerond, prune wordt pas uitgevoerd nadat de repository het exclusieve venster is binnengegaan en check volgt het gekozen onderhoudsbeleid. Gebruik een gedeelde externe poort waar alle relevante units zich aan houden.

Systemd-targets kunnen vastleggen dat afhankelijkheden tussen back-up en onderhoud in de juiste volgorde moeten worden voltooid in plaats van alleen op verschillende tijdstippen te starten.

Stel begrensde nieuwe pogingen in voor vergrendelingsconflicten en netwerkfouten en geef een waarschuwing wanneer de deadline wordt gemist. Een vertraagde back-up moet prune uitstellen; een uitgelopen prune moet de volgende back-up uitstellen en de beheerder waarschuwen. Geforceerd ontgrendelen en opties zonder vergrendeling zijn geen beleid voor nieuwe pogingen.

Controleer twee volledige cycli en één herstel

Bekijk twee volledige cycli in plaats van succes te verklaren zodra de timerbestanden zijn geladen. Controleer of elke bron de verwachte snapshot oplevert, forget de bedoelde groepen bewaart, prune alleen binnen het venster wordt uitgevoerd, vergrendelingen na schone afsluitingen verdwijnen en waarschuwingen elke vertraging registreren.

Herstel bestanden uit een snapshot die de retentie- en prunereeks heeft overleefd, niet alleen uit de nieuwste back-up. Daarmee bewijs je dat het volledige schema een bruikbaar herstelpunt bewaart in plaats van alleen groene taakstatussen te produceren.

Het schema slaagt wanneer twee cycli in de juiste volgorde zijn voltooid, geen taak stilzwijgend verdwijnt, de bewaarde snapshots overeenkomen met de preview en het voorbeeldherstel correct is. Draai de onderhoudsautomatisering terug maar behoud normale back-ups als retentie de verkeerde groep verwijdert, prune niet betrouwbaar kan voltooien of vergrendelingsconflicten terugkeren. Pas de frequentie aan op basis van gemeten resultaten, niet door repositorybescherming uit te schakelen.