Backup-аа түгжсэн ч устгаж болно: S3 Object Lock-ийн эрхийг давхар шалга

Restic backup-ийг S3-compatible хадгалалтад тогтоосон хугацаанд устгуулахгүй байлгахын тулд versioning болон Object Lock идэвхтэй bucket-д анхдагч хадгалах хугацаа тохируул. Дараа нь шинээр бичигдсэн pack файлын хувилбарт хамгаалалт тавигдсан эсэх, backup-ийн credential түүнийг тойрч чадах эсэх, файлуудыг буцаан сэргээж болох эсэхийг тус тусад нь шалга. AWS-ийн Object Lock баримтжуулалтад хамгаалалт нь object-ийн хувилбарт үйлчилдэг бөгөөд энгийн устгал хамгаалсан хувилбарын дээр delete marker үүсгэж болохыг тайлбарласан.

Bucket дээр «Object Lock enabled» гэж харагдах нь backup хамгаалагдсаны нотолгоо биш. Шалгалт амжилттай болохын тулд шинэ pack хувилбарт retention mode, дуусах хугацаа бичигдсэн байх, хамгаалалтыг тойрох эрхгүй credential тэр хувилбарыг устгаж чадахгүй байх, хоосон байрлалд сэргээсэн файлууд эх өгөгдөлтэйгээ таарах шаардлагатай. Эдгээрийн аль нэг нь биелэхгүй бол тохиргооны нэрнээс сэргээх чадварыг дүгнэж болохгүй.

Bucket болон хадгалах хугацааг бэлдэх

Нөөцлөлт эхлэхээс өмнө bucket-ийн versioning төлөв болон Object Lock дүрмийг шалга. AWS CLI-ийн get-bucket-versioning тушаал versioning-ийн төлөвийг, get-object-lock-configuration тушаал bucket-ийн Object Lock болон анхдагч retention-ийг харуулна. S3-compatible үйлчилгээ хэрэглэж байгаа бол тухайн үйлчилгээ эдгээр API болон Object Lock горимуудыг хэрхэн хэрэгжүүлснийг өөрийнх нь заавраас нягтал: Amazon S3-д ажилладаг тохиргоо бусад endpoint дээр адил ажиллана гэсэн баталгаа байхгүй.

Анхдагч retention дүрэмд GOVERNANCE эсвэл COMPLIANCE горим, хадгалах хугацааг сонго. Энэ дүрэм цаашид шинээр бичигдэх object-ийн хувилбарт үйлчилнэ; өмнө нь хадгалсан хувилбаруудыг автоматаар хамгаалагдсан гэж үзэхгүй. Хугацааг хэрэгтэй хамгийн хуучин сэргээх цэг, backup-ийн давтамж, хадгалалтын зардалтай уялдуул. Богино хугацаа шаардлагатай сэргээх цэгээс өмнө дуусаж болох бол урт хугацаа хуучин хувилбаруудын зайг чөлөөлөхийг хойшлуулна.

GOVERNANCE горим тусгай эрхтэй хэрэглэгчид хамгаалсан хувилбарыг устгах боломж үлдээдэг. COMPLIANCE горимд Amazon S3-ийн хамгаалсан хувилбарыг хадгалах хугацаа дуусахаас өмнө устгах, хугацааг нь богиносгох боломжгүй. Иймээс горим сонгохдоо халдлагын үед хэрэгтэй сэргээх цонхыг төдийгүй хугацаа дуусаагүй өгөгдлийг арилгах шаардлага гарвал ямар үр дагавартайг тооц.

Restic-ийг бичүүлж, устгах эрхийг тусгаарлах

Restic repository-г сонгосон bucket рүү зааж, нууц үгийн файлаа тохируулаад restic init болон бага хэмжээний туршилтын өгөгдөлд restic backup ажиллуул. S3-compatible endpoint ашиглавал restic repository-ийн хаяг, AWS CLI-ийн endpoint, bucket-ийн нэр гурав нэг хадгалалт руу зааж байгааг тулга. Хамгаалалт шалгахдаа production repository-ийн жинхэнэ pack-ийг устгах шаардлагагүй; тусдаа туршилтын repository эсвэл зориуд үүсгэсэн object ашигла.

Өдөр тутмын backup credential-д s3:BypassGovernanceRetention, object-ийн хувилбар устгах, retention болон bucket-ийн lock дүрэм өөрчлөх эрх байгаа эсэхийг тус бүрээр нь шалга. AWS-ийн governance горимын эрхийн тайлбар bypass эрхтэй хүсэлт хамгаалсан хувилбарыг устгах эсвэл хадгалах хугацааг богиносгох боломжтойг заадаг. CLI болон API-д тойрох үйлдлийг хүсэлтдээ илэрхий заах шаардлагатай бол S3 консол эрхтэй хэрэглэгчийн хүсэлтэд bypass тэмдэглэгээг автоматаар нэмдэг.

Өдөр тутмын түлхүүрт өргөн хүрээний admin эрх байвал GOVERNANCE хамгаалалт тэр түлхүүр алдагдах үед сул болно. Backup бичих эрхийг retention-ийн бодлого засах болон governance хамгаалалтыг тойрох эрхээс тусгаарла. IAM болон bucket policy дээр зөвхөн backup role-ийн нэрийг хараад зогсохгүй өөр role авах, шинэ credential үүсгэх эрхээр дамжин устгах зөвшөөрөлд хүрч болох эсэхийг шалгах нь зүйтэй.

Шинэ pack-ийн хамгаалалтыг хувилбар дээр нь шалгах

Backup дууссаны дараа repository-ийн data/ хэсгээс шинээр бичигдсэн pack object сонго. list-object-versions тушаалаар түүний version ID-г авч, head-object эсвэл get-object-retention хүсэлтэд яг тэр ID-г заан ObjectLockMode болон ObjectLockRetainUntilDate утгыг хар. Сонгосон горим, ирээдүйн дуусах хугацаа хоёулаа тухайн хувилбарт байх ёстой. Bucket-ийн анхдагч дүрэм харагдаж байгаа нь pack дээр retention буусныг дангаараа батлахгүй.

Repository-ийн snapshot болон index object-уудаас мөн шинэ хувилбар сонгон шалга. Pack хамгаалагдсан байлаа ч сэргээхэд хэрэгтэй бусад object ижил нөхцөлтэй гэсэн үг биш. Metadata хоосон харагдвал retention байхгүй гэж шууд дүгнэхээс өмнө шалгаж буй credential-д s3:GetObjectRetention зөвшөөрөл байгаа эсэхийг нягтал.

Дараа нь туршилтын object-ийн version ID-г заасан устгах хүсэлтийг bypass эрхгүй credential-ээр илгээ. Хадгалах хугацаа хүчинтэй байхад хүсэлт татгалзах ёстой. Устгал амжилттай болбол горим, дуусах хугацаа, хүсэлтэд заасан version ID болон ашигласан credential-ийг дахин тулга; зөвхөн metadata-г уншсан үр дүн хамгаалалт хэрэгжиж байгааг бүрэн нотлохгүй.

Delete marker болон сэргээх сорил

Хамгаалсан хувилбар үлдсэн ч энгийн устгал repository-ийн одоогийн харагдах хувилбарыг delete marker-ээр халхалж болно. XNS-ийн restic туршилтад анхдагч retention шинэ pack-д үйлчилж, version ID-тай устгах хүсэлт татгалзсан; харин энгийн устгалын дараа restic check pack-ийг ололгүй алдаа заасан. Marker-ийн version ID-г зааж арилгахад шалгалт дахин амжилттай болсон. Энэ нь XNS-ийн туршсан тохиргооны үр дүн тул өөр S3-compatible үйлчилгээнд өөрийн сорил хэрэгтэй.

Өөрийн туршилтын repository дээр restic check ажиллуулаад restic restore latest --target ЗОРИЛТОТ_ХАВТАС тушаалаар хоосон байрлалд сэргээ. Эх өгөгдөл болон сэргээсэн файлуудын нэр, хэмжээ, checksum-ийг харьцуул. Restore тушаал алдаагүй дуусах нь бүх файл таарсныг дангаараа нотлохгүй; нууц үг, S3 credential болон сүлжээний холболт сэргээх үед үнэхээр олдож байгаа эсэх ч энэ сорилд илэрнэ.

Энгийн устгалын нөлөөг турших бол зөвхөн тусдаа test repository ашигла. list-object-versions доторх delete marker-ийг хамгаалсан pack хувилбараас ялгаж, marker-ийн version ID-г зааж арилгасны дараа restic check болон restore-ийг дахин ажиллуул. Хамгаалсан хувилбар хадгалалтад хэвээр байсан ч marker арилахаас нааш restic түүнийг ердийн унших замаар авахгүй байж болно.

Хадгалах зардлыг тооцохдоо restic forget --prune-ийн тайланд гарсан чөлөөлсөн зайг bucket-ийн бодит ашиглалттай адилтгаж болохгүй. Хугацаа нь дуусаагүй хуучин хувилбарууд Object Lock-ийн улмаас хадгалалтад үлдэж, зай эзэлсээр байж болно. Сэргээх цонхоо уртасгах шийдвэр ийм хувилбаруудын хадгалагдах хугацааг мөн уртасгана.

Мөн уншаарай:

• Facebook Privacy Checkup хангалтгүй: tag, хуучин постоо давхар шалга
• HubSpot эсвэл Zoho CRM: хямд суудал тохиргооны цагийг нууж болно
• Cloudflare эсвэл Google DNS: нууцлалын ялгаа хурднаас том байж болно