I-backup ang container o ang mga file sa loob nito? Magpasya ayon sa hugis ng pag-restore

Maaari mong i-backup ang isang naka-encrypt na container bilang isang bagay, o i-mount ito at i-backup ang mga file sa loob. Pareho silang dumadaan sa VPN nang maayos, at doon nagtatapos ang pagkakatulad. Magkaiba ang nire-restore nila, umaasa sila sa magkaibang susi, magkaiba ang tindi ng espasyong ginagamit, at magkaiba ang paraan ng pagpalya kapag may kailangang ibalik ang datos. Piliin muna ang bagay na ire-restore, pagkatapos ang transportasyon, pagkatapos ang encryption ng nakaimbak na kopya. Ang checklist sa ibaba ay sumusunod sa ayos na iyon, dahil halos lahat ng pagtatalo tungkol sa backup ay talagang hindi pagkakasundo kung alin sa tatlong desisyong iyon ang unang ginawa.

Dalawang bagay, dalawang hugis ng pag-restore

Ang backup sa antas ng imahe ay nagre-restore ng container: nakukuha mo ang naka-encrypt na volume pabalik at kailangan mo pa rin ang restore material nito para buksan ito. Ang backup sa antas ng file ay nagre-restore ng mga file at puno ng direktoryo, at anumang encryption na nagpoprotekta sa kanila ay katangian ng repository ng backup, hindi ng orihinal na container. Ang simpleng kopya sa malayong folder ay ikatlong kaso, at namamana nito ang proteksyong aksidenteng mayroon ang folder na iyon.

Ang gitnang hilera ang madalas maling basahin. Maaari itong maging tunay na magandang disenyo: binabasa ng backup program ang plaintext nang lokal at nagsusulat ng naka-encrypt at na-authenticate na repository. Ang seguridad noon ay nakasalalay sa programang iyon at sa mga kredensyal nito, hindi sa password ng orihinal na container, at hindi dapat ilarawan ang dalawa na parang isang kontrol.

Pagsusuri 1: ano ang dapat itayong muli ng pag-restore?

Itanong ito sa anyo ng pag-restore, hindi ng backup. Kung ang pangangailangan ay “ibalik ang serbisyong ito sa ibang host”, ang imahe at ang restore material nito ay magkakaugnay na sagot. Kung ang pangangailangan ay “ibalik ang spreadsheet sa pananalapi ng Marso”, ang pag-restore ng imaheng may ilang gigabyte para lang kunin ang isang file ay mamahaling sagot. Pareho silang lehitimong pag-restore, at hindi sila mapagpapalit na badyet. Ang planong nagbabanggit lamang ng isa sa kanila ay sa huli susubukan ng isa pa.

Isulat sa plano ang target ng pag-restore: buong volume, puno ng direktoryo, o indibidwal na file. Pagkatapos, itala kung anong metadata ang kailangang sumama sa kanila, dahil ang pagmamay-ari, mga pahintulot, pinahabang katangian at timestamp ay bahagi ng pag-restore sa antas ng file at madalas mawala sa mga daloy ng trabahong nakabatay sa kopya na tila sapat noong pagsubok.

Magpasya rin kung sino ang gagawa ng pag-restore. Ang repository sa antas ng file na kayang i-mount ng kahit sinong operator ay ibang modelo ng pag-access kaysa sa imaheng nangangailangan ng presensya ng may-ari ng susi, at wala sa kanila ang awtomatikong mas mabuti. Ang mahalaga ay ang pagpiling sinadya at nakasulat.

Pagsusuri 2: ano ang nagpoprotekta sa nakaimbak na kopya?

Pinoprotektahan ng VPN ang isang bahagi ng transportasyon. Wala itong sinasabi tungkol sa nakaimbak na kopya kapag tapos na ang paglilipat, at ang “dumaan ito sa tunnel” ay hindi pahayag tungkol sa kakayahan ng operator ng backup na basahin ang datos mo. Kung ang malayong panig ay pinapatakbo ng ibang tao, ang tanong ay ano ang mababasa nila, hindi kung naka-encrypt ang koneksyon.

Para sa imahe, ang ibig sabihin nito ay protektahan ang key material ng container nang hiwalay sa imahe mismo. Ang mawala ang header ay mawala ang volume, kaya i-backup ang header sa lugar kung saan wala ang imahe:

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

Para sa repository sa antas ng file, tiyakin na ine-encrypt at na-a-authenticate ng tool ang nilalaman at metadata bago umalis sa host, at alamin kung sino ang may hawak ng mga susi. Ang dokumentasyon ng disenyo ng Restic ay malinaw na ipinapalagay nito ang pinagkakatiwalaang source host at na hindi pinipigilan ng encryption ang sinumang may access sa storage na magtanggal ng mga backup. Mahalaga ang dalawang paalala: ang repository ay maaaring kompidensyal at buhay pa ring masira.

Pagsusuri 3: pare-pareho ba ang kopya?

Ang backup na kumukuha ng nagbabagong filesystem ay kopya, hindi restore point. Para sa imahe, gamitin ang sinusuportahang paraan ng volume tool para sa matatag na snapshot, na karaniwang nangangahulugang operasyon ng snapshot o pag-unmount kaysa sa pagbasa ng malaking file habang nagbabago ito:

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

Para sa mga naka-mount na file, gamitin ang sinusuportahang pamamaraan ng consistency ng application para sa mga aktibong database at iba pang koordinadong datos. Ang kopya sa antas ng filesystem at ang restore point na pare-pareho sa application ay magkaibang paglalarawan, at ang pagkakaiba ay makikita lamang kapag sinubukan mong simulan ang application mula sa na-restore na kopya.

Panatilihin ang restore material sa isang malayang protektadong ruta. Ang pagkawala ng orihinal na makina ay hindi dapat kailanman mangahulugan ng pagkawala rin ng nag-iisang kredensyal na nagbubukas ng backup nito, at iyon mismo ang nangyayari kapag ang key file ay nakatira sa volume na binabackup. Subukan ang paghihiwalay na iyon nang sinasadya: mag-restore sa host na hindi pa nakakita ng orihinal, gamit lamang ang sinasabi ng plano na available.

Pagsusuri 4: nalalapat ba ang pagtuklas ng pagbabago sa bagay na ito?

Ang naka-encrypt na container ay mukhang isang malaking mala-bulong na file sa karamihan ng tool sa paglilipat, kaya ang maliit na pagbabago sa plaintext ay maaaring magdulot ng malaking muling pagbasa o buong muling pag-upload depende sa tool at format. Ang paghahati sa mga tipak na may variable na laki at deduplication, gaya ng dokumentado ng restic, ay makakabawas niyon, ngunit katangian iyon ng tool na iyon at hindi ng mga naka-encrypt na container sa pangkalahatan.

Magtakda ng sukat sa halip na magpalagay. Itugma ang unang takbo sa ikalawa pagkatapos ng maliit at hindi nakakasamang pagbabago, at itala ang mga byte na nailipat pati ang lumipas na oras. Panatilihin ang isang backup na alam na maayos habang nag-eeksperimento, para hindi maubos ng isang pagsubok ang nag-iisa mong restore point.

Pagkatapos, tapusin ang checklist sa nag-iisang pagsubok na mahalaga: pag-restore na wala ang orihinal na makina. Buksan ang na-restore na container, o i-restore ang mga piniling file kasama ang kanilang metadata, at tiyakin na magagamit ng application o ng user ang resulta. Ang mabilis at mahusay na naka-encrypt na paglilipat na hindi makasagot sa pagsubok na iyon ay kopya ng datos mo, hindi backup nito.