Back-up fan 'e container of fan syn bestannen? Kies op basis fan 'e foarm fan weromsetten

Jo kinne in fersifere container as ien objekt back-uppe, of him mounte en de bestannen derbinnen back-uppe. Beide geane fleurich troch de VPN, en dêr einiget de oerienstimming. Se sette ferskillende dingen werom, se fertrouwe op ferskillende kaais, se kostje ferskillende hoemannichten romte, en se fâlje op ferskillende wizen as immen de gegevens werom nedich hat. Kies earst it weromsetobjekt, dan it ferfier, dan de fersifering fan 'e bewarre kopy. De checklist hjirûnder rint yn dy folchoarder, om't hast elk back-upgeskil eins in meningsferskil is oer hokker fan dy trije as earste besletten waard.

Twa objekten, twa foarmen fan weromsetten

In ôfbyldingsback-up set in container werom: jo krije it fersifere volume werom en hawwe noch altyd syn weromsetmateriaal nedich om it te iepenjen. In bestânsback-up set bestannen en mappebeammen werom, en hokker fersifering se ek beskermet is in eigenskip fan it back-updepot, net fan 'e oarspronklike container. In gewoane kopy nei in map op ôfstân is in tredde gefal, en it erft de beskerming dy't dy map tafallich hat.

De middenrige is dy't minsken ferkeard lêze. It kin in folslein goed ûntwerp wêze: it back-upprogramma lêst pleatslik platte tekst en skriuwt in fersifere, autentisearre depot. Dan rêst de feiligens op dat programma en syn credentials, net op it wachtwurd fan 'e oarspronklike container, en de beide moatte net beskreaun wurde as wiene se deselde kontrôle.

Kontrôle 1: wat moat it weromsetten wer opbouwe?

Stel de fraach yn 'e foarm fan in weromsetting, net fan in back-up. As de eask is “bring dizze tsjinst werom op in oare host”, dan is in ôfbylding mei syn weromsetmateriaal in gearhingjend antwurd. As de eask is “krij it finansjele rekkenblêd fan maart werom”, dan is it weromsetten fan in ôfbylding fan ferskate gigabytes om ien bestân te lûken in djoere manier om te antwurdzjen. Beide binne legitime weromsettings, en it binne gjin útwikselbere budgets. In plan dat mar ien fan beide neamt, sil úteinlik troch de oare test wurde.

Skriuw it weromsetdoel yn it plan: hiel volume, in mappebeam of losse bestannen. Skriuw dan op hokker metadata mei moatte reizgje, om't eigenskip, rjochten, útwreide attributen en tiidstempels diel binne fan in bestânsback-up en faak ferlern geane yn op kopyjen basearre workflows dy't by it testen genôch lieken.

Beslis ek wa't it weromsetten docht. In bestânsdepot dat elke operator mounte kin is in oar tagongsmodel as in ôfbylding dy't de oanwêzigens fan 'e kaaihâlder freget, en gjin fan beide is automatysk better. Wat fan belang is, is dat de kar bewust en opskreaun is.

Kontrôle 2: wat beskermet de bewarre kopy?

De VPN beskermet in ferfiersegment. Hy seit neat oer de bewarre kopy as de oerdracht dien is, en “it gie troch de tunnel” is gjin útspraak oer it fermogen fan 'e back-upoperator om jo gegevens te lêzen. As de ôfstânkant troch immen oars bestjoerd wurdt, is de fraach wat sy lêze kinne, net oft de ferbining fersifere wie.

Foar in ôfbylding betsjuttet dat it kaaimateriaal fan 'e container apart fan 'e ôfbylding beskermje. De kop ferlieze is it volume ferlieze, dus back-up de kop earne dêr't de ôfbylding net is:

cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20

Foar in bestânsdepot kontrolearje dat it ark ynhâld en metadata fersifere en autentisearret foardat se de host ferlitte, en útfine wa't de kaais hat. De ûntwerpdokumintaasje fan Restic is dúdlik dat it in fertroude boarnehost ferûnderstelt en dat fersifering net foarkomt dat immen mei tagong ta de opslach back-ups wisket. Beide foarbehâlden binne fan belang: in depot kin fertroulik wêze en dochs ferneatige wurde.

Kontrôle 3: is de kopy konsekwint?

In back-up dy't in feroarjend bestânssysteem fêstleit is in kopy, gjin weromsetpunt. Foar in ôfbylding brûk de stipe metoade fan it volumeark foar in stabile momentopname, wat meastentiids in momentopname-operaasje of in ûntmounting betsjuttet ynstee fan it lêzen fan in grut bestân wylst it feroaret:

lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly

Foar mounte bestannen brûk de stipe konsekwinsjeproseduere fan 'e applikaasje foar aktive databanken en oare koördinearre gegevens. In kopy op bestânssysteemnivo en in mei de applikaasje konsekwint weromsetpunt binne ferskillende beskriuwings, en it ferskil wurdt pas sichtber as jo de applikaasje fan 'e weromsette kopy ôf starte probearje.

Hâld it weromsetmateriaal op in ûnôfhinklike beskerme rûte. It ferliezen fan 'e oarspronklike masine moat nea ek de iennige credential ferlieze dy't syn back-up iepenet, en dat is krekt wat bart as it kaai-bestân op it volume wennet dat back-upt wurdt. Test dy skieding bewust: set werom op in host dy't it origineel nea sjoen hat, en brûk allinnich wat it plan seit dat beskikber is.

Kontrôle 4: jildt feroaringsdeteksje foar dit objekt?

In fersifere container liket foar de measte oerdrachtarken op ien grut ûntrochsichtich bestân, dus in lytse bewurking yn platte tekst kin in grutte weromlêzing of in folsleine weroplaad feroarsaakje, ôfhinklik fan it ark en it formaat. Fariabele blokgrutte en deduplicaasje, sa't restic dokumintearret, kinne dat ferminderje, mar it is in eigenskip fan dat ark en net fan fersifere containers yn 't algemien.

Mjit ynstee fan oan te nimmen. Fergelykje in earste run mei in twadde nei in lytse, ûnskealike feroaring, en skriuw sawol de oerdroegen bytes as de ferstrutene tiid op. Bewarje in bekend-goede back-up wylst jo eksperimintearje, sadat in test jo iennige weromsetpunt net opbrûkt.

Finish dan de checklist mei de iennige test dy't telt: weromsette sûnder de oarspronklike masine. Iepenje in weromsette container, of set selektearre bestannen mei har metadata werom, en befêstigje dat de applikaasje of de brûker it resultaat brûke kin. In flugge, goed fersifere oerdracht dy't dy test net beantwurdzje kin is in kopy fan jo gegevens, net in back-up derfan.