Controlelijst voor het beoordelen van snapshotbewaring voor een NAS thuis

De veilige aanpak is om inventarissnapshots te behandelen, ze aan hersteldoelen en afhankelijkheden te koppelen en de bewaartermijn vervolgens met een omkeerbare pilot te wijzigen als een reeks observeerbare poorten, niet als één opdracht.

Op een ZFS- of Btrfs-thuis-NAS bestaat het praktische risico eruit dat de snapshotgeschiedenis, het capaciteitsgebruik en de hersteldekking niet langer aansluiten op de huidige behoeften. Leg de huidige identiteit en het herstelpunt vast, begin met de minst ingrijpende onderscheidende controle, interpreteer de geslaagde en mislukte resultaten voordat je een andere variabele wijzigt en stop wanneer de opslag instabiel wordt of de enige herstelbare kopie zou worden blootgesteld. De onderstaande workflow eindigt pas nadat de oorspronkelijke werklast slaagt of het bewijsmateriaal een escalatiegrens bereikt.

Inventariseer schema's, eigenaars en daadwerkelijke snapshots

Maak een lijst van elke snapshottaak, dataset of subvolume, frequentie, naamgevingsregel, bewaartermijn, eigenaar en laatste geslaagde uitvoering. Maak vervolgens een lijst van de snapshots die daadwerkelijk bestaan. Verschillen brengen uitgeschakelde schema's, handmatig bewaarde uitzonderingen, dubbele hulpprogramma's of snapshots aan het licht die niet langer door een beleid worden beheerd.

Een snapshot is een bestandssysteemweergave op een bepaald tijdstip, terwijl de benodigde ruimte groeit naarmate livegegevens veranderen. De Princeton-opslaghandleiding legt het ruimtegedrag van snapshots uit en waarom bewaarde blokken meetellen voor de beschikbare capaciteit, zelfs wanneer de live-boom ze niet langer toont.

Verwijder niets tijdens de inventarisatie. Markeer onbekende snapshots als beschermd totdat hun maker, replicatierol en herstelwaarde bekend zijn. De fase is geslaagd wanneer elke snapshot bij een gedocumenteerd beleid of een expliciete uitzondering hoort.

Koppel elke laag aan een herstelvraag

Schrijf voor elke dataset op welke herstelvragen deze moet beantwoorden: een bestandswijziging van vandaag ongedaan maken, een vorige week verwijderde map herstellen, een app-update terugdraaien of offsite-replicatie starten. Bouw uur-, dag-, week- en maandlagen alleen waar deze vensters overeenkomen met echte herstelbehoeften.

Tel geslaagde herstelpunten, niet geplande labels. Een hoogfrequente laag die drie dagen geleden is gestopt, kan niet aan een kort hersteldoel voldoen, en een maandelijkse snapshot van snel veranderende appgegevens kan te grof zijn, ook al is deze oud. Neem onveranderlijke of off-host back-ups afzonderlijk op, omdat lokale snapshots geen onafhankelijke kopieën zijn.

Verwijder een voorgestelde laag uit het plan als niemand een herstelgeval ervoor kan noemen. Voeg dekking toe wanneer een kritieke dataset geen snapshot of back-up heeft die aansluit op de veranderingssnelheid, maar compenseer ontbrekende back-ups niet door lokale snapshots voor altijd te bewaren.

Controleer ruimte- en replicatieafhankelijkheden vóór het opschonen

Meet op hetzelfde tijdstip de ruimte die door snapshots wordt vastgehouden, de livegegevens waarnaar wordt verwezen, de vrije poolruimte en de recente veranderingssnelheid. Controleer op ZFS de gebruikte en verwezen ruimte per snapshot; vergelijk op Btrfs de subvolume-inventaris, qgroup-gegevens wanneer die betrouwbaar zijn en de bestandssysteemallocatie. Voorspel teruggewonnen ruimte niet uitsluitend op basis van de schijnbare grootte van een snapshot.

Gebruik de ZimaSpace-workflow om te bepalen of snapshots of prullenbakken NAS-ruimte gebruiken voordat je de bewaartermijn wijzigt. Hiermee voorkom je dat een schatting op basis van zichtbare mappen wordt aangezien voor blokken die door snapshots of een prullenbaklaag worden vastgehouden.

Identificeer snapshots die worden gebruikt als basis voor incrementele replicatie, afhankelijkheden voor het hervatten van ontvangsten, bladwijzers, klonen of terugdraaipunten voor huidig onderhoud. Als verwijdering een volledige nieuwe seed zou afdwingen of een kloon zou verbreken, wijzig dan eerst het replicatieplan en bewaar de gedeelde basis totdat de nieuwe keten is geverifieerd.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Test de nieuwe regel en bewijs dat herstel nog werkt

Pas de nieuwe bewaartermijn toe op één dataset met laag risico of bekijk de verwijderlijst vooraf wanneer de tool een proefrun ondersteunt. Sla de namen en tijdstippen op die zouden overblijven en bevestig vervolgens dat aan de oudste en nieuwste herstelvereisten nog steeds wordt voldaan voordat je de wijziging definitief maakt.

Controleer na verwijdering het gedrag van de vrije ruimte, de volgende geplande snapshot, incrementele replicatie en het herstel van één recent en één ouder bestand. Een beleid dat ruimte bespaart maar de verzendketen verbreekt of het enige punt vóór een upgrade verwijdert, is mislukt.

Voer de regel pas definitief in nadat twee schemacycli de bedoelde lagen hebben opgeleverd en waarschuwingen gemiste snapshots afdekken. Stop en herstel het vorige beleid als replicatie de volledige omvang krijgt, snapshots uit de herstelinterface verdwijnen of de resterende geschiedenis niet langer aan de vastgelegde herstelvragen voldoet.