Afzonderlijke ZFS-datasets instellen voor appgegevens, back-ups en downloads

Stel afzonderlijke ZFS-datasets in voor appgegevens, back-ups en downloads door elke workload een eigen mountpoint, eigenschappen, snapshotbeleid en opruimgrens te geven.

Op een homeserver staan deze mappen vaak aanvankelijk in één grote share, omdat dat eenvoudig is. Later hebben ze vaak verschillende bewaartermijnen, rechten, compressie, recordsize, quota’s en herstelgedrag nodig. Daarom is het verstandig ze op te splitsen voordat één luidruchtige workload het beleid voor al het andere bepaalt.

Bepaal wat elke dataset moet beschermen

Begin met de functie van elke workload. Appgegevens hebben meestal consistente snapshots en zorgvuldig herstel nodig, back-ups hebben capaciteitsbeheer en bewaartermijnen nodig, en downloads moeten eenvoudig kunnen worden opgeschoond zonder onderdeel te worden van langdurige bescherming.

ZFS-datasets zijn niet alleen mappen, maar ook administratieve grenzen. Eigenschappen zoals compressie, quota’s en reserveringen, mountpoints en snapshots kunnen per dataset worden beheerd. Daarom is het nuttig workloads te scheiden, zelfs wanneer ze in dezelfde pool staan.

Noteer de drie beoogde rollen voordat je iets aanmaakt: appstatus die je zou herstellen, back-upgegevens die je zou bewaren en wegwerpbare of opnieuw te downloaden gegevens die je zou opruimen. Als twee mappen hetzelfde herstel- en opruimbeleid nodig hebben, zijn afzonderlijke datasets misschien nog niet nodig.

Maak duidelijke mountpoints voordat je gegevens verplaatst

Kies mountpoints die de scheiding duidelijk maken voor apps en mensen. Een eenvoudige indeling gebruikt bijvoorbeeld één bovenliggende map zoals /srv/storage, met daaronder mountpoints voor appdata, backups en downloads.

De zfs-set-documentatie van OpenZFS beschrijft hoe je dataset-eigenschappen instelt met zfs set. De uitgebreidere documentatie over eigenschappen behandelt het gedrag van mountpoints en het overnemen van eigenschappen. Daardoor kun je een bovenliggende dataset met gedeelde standaardinstellingen maken en alleen de onderliggende datasets aanpassen die ander gedrag nodig hebben.

Maak eerst lege datasets aan, controleer of ze op de verwachte locaties worden aangekoppeld en verplaats daarna pas de gegevens. Stop als een applicatie nog naar het oude pad schrijft. Migreer die applicatie tijdens een onderhoudsvenster, zodat je netjes kunt terugrollen.

Geef appgegevens het zorgvuldigste snapshotbeleid

Appgegevens veranderen meestal in kleine maar belangrijke stappen: databases, configuratiebestanden, uploads van gebruikers, containervolumes en applicatiestatus. Het verlies van één bestand is misschien minder zichtbaar dan het verlies van een volledige back-upmap, maar herstellen naar het verkeerde moment kan een app defect maken.

De documentatie over OpenZFS-eigenschappen laat zien dat eigenschappen op datasetniveau kunnen worden overgenomen of overschreven. Zo kunnen appgegevens frequentere snapshots of andere compressie gebruiken zonder die keuzes aan downloads op te leggen.

Kies voor appgegevens bij voorkeur frequente snapshots, terughoudend opschonen en een hersteltest voor één representatieve applicatie. Als een app een actieve database gebruikt, stem snapshots dan af op de eigen back-up- of pauzemethode van de app in plaats van ervan uit te gaan dat een bestandssystemsnapshot consistent is met de applicatie.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Geef back-ups capaciteitslimieten en bewaartermijnen

Back-ups verdienen een eigen dataset omdat ze ongemerkt kunnen groeien door bewaartermijnen, deduplicatiemetagegevens, synthetische volledige back-ups, replicatie of oude clienttaken. Een back-updataset zonder limiet kan de ruimte opsouperen die apps of actieve shares nodig hebben.

De ZFS-gids van Oracle beschrijft quota’s en reserveringen als instellingen op datasetniveau. Daardoor zijn ze nuttig om te voorkomen dat back-ups uitgroeien ten koste van andere workloads.

Stel een quota of op zijn minst een waarschuwingsdrempel in voor de back-updataset en stem de bewaartermijn van snapshots af op die van de back-uptool. Bewaar geen bestandssysteemsnapshots voor altijd rond back-upbestanden die de back-upapplicatie zelf al als opgeschoond beschouwt.

Houd downloads eenvoudig opnieuw op te bouwen en te verwijderen

Downloads zijn meestal de minst belangrijke dataset, omdat de meeste bestanden tijdelijk zijn, opnieuw kunnen worden gedownload of alleen worden opgeslagen voordat ze worden gesorteerd. Toch verdienen ze een eigen grens, omdat ze een pool snel kunnen vullen en snapshots kunnen overnemen die ze niet nodig hebben.

Met een afzonderlijke downloads-dataset kun je langdurige bewaartermijnen verkorten of uitschakelen, compressie afstemmen op het bestandstype en de map opschonen zonder appstatus of back-ups aan te raken.

Gebruik een klein quota of planmatig opruimen als downloads regelmatig alle ruimte innemen. Als een bestand belangrijk wordt, verplaats het dan naar de dataset waarvan het beleid bij de nieuwe rol past, in plaats van gegevens voor de lange termijn in het wegwerpgebied te bewaren.

Controleer rechten, snapshots en herstel na de splitsing

De configuratie is niet klaar zodra de datasets bestaan. Ze is klaar wanneer apps correct starten, back-ups in de juiste dataset terechtkomen, downloads veilig kunnen worden opgeschoond en snapshots de verwachte grenzen laten zien.

Voer per categorie één herstelcontrole uit: herstel een kleine appconfiguratie, toon een herstelpunt van een back-up en verwijder of ruim een testdownloadbestand op. Zo controleer je of de datasetgrens overeenkomt met de operationele grens.

Als een snapshot onverwacht downloads bevat of appgegevens mist, stop dan en herstel het mountpoint of de datasettoewijzing voordat je meer automatisering toevoegt. Het gewenste eindresultaat is saai: voor elke workload is er een beleid dat je in één zin kunt uitleggen.

Veelgestelde vragen

Moeten appgegevens en back-ups ooit één dataset delen?

Alleen als ze echt dezelfde vereisten hebben voor bewaartermijn, quota, snapshots en herstel. Op de meeste homeservers hebben appgegevens en back-ups verschillende beleidsregels nodig.

Kan ik datasets splitsen nadat er al gegevens bestaan?

Ja, maar behandel dit als een migratie. Maak de nieuwe datasets aan, stop de apps of taken die schrijven, verplaats de gegevens, werk de paden bij, test alles en bewaar de oude kopie totdat de nieuwe mountpoints zijn gecontroleerd.

Bekijk voor een gerelateerde planningsstap hoe datasetgrenzen samenhangen met replicatiecapaciteit. ZimaSpace’s handleiding over het vullen van een bestemmingspool door snapshotreplicatie laat zien waarom bewaartermijn en datasetscope samen moeten worden ontworpen.