Аппликешнийнхээ мэдээллийн сангийн нөөцлөлтийг хэрхэн хийх (мөн үнэхээр сэргээх)

Аппликешнийнхээ мэдээллийн санг нөөцлөхийн тулд түүнийг хуваарийн дагуу файл руу экспортлож, хуулбаруудыг мэдээллийн сангаас тусдаа газар хадгалж, тогтмол нэгийг нь хоосон мэдээллийн санд сэргээж ажиллаж байгааг батална. Эрсдэлтэй өөрчлөлтийн өмнө нэмэлт нөөцлөлт хий. Кодын нөөцлөлт, GitHub репозитори эсвэл экспорт аль нь ч болов, өгөгдлөө агуулахгүй.

Энэ гарын авлага нь аппликешнээ ажиллуулдаг, алдахаас айхаа больмоор жижиг аппликешны эзэдэд зориулагдсан. Жишээнд Postgres ашигласан, учир нь ихэнх AI-ээр бүтээсэн аппликешн үүнийг ашигладаг, гэхдээ зарчмууд ямар ч мэдээллийн санд хамаарна.

Нөөцлөлт юуг хамруулах ёстой вэ

Аппликешн бол зөвхөн мэдээллийн сан биш. Аль хэсгийг аль нөөцлөлт хамгаалдагийг мэдэж байх хэрэгтэй.

Өгөгдөл бол дахин үүсгэх боломжгүй цорын ганц хэсэг. Код дахин бичигдэж, тохиргоо дахин оруулагдаж болно; харин таны харилцагчдын захиалгыг буцааж гаргаж чадахгүй.

Алхам 1: Хэр их алдаж болохыг шийд

Нөөцлөлтийн төлөвлөгөөг хоёр асуулт тодорхойлно:

• Хамгийн сүүлийн хэр их өгөгдлөө алдаж болох вэ? Хэрэв өдөрт нэг удаа нөөцөлж, мэдээллийн сан оройд эвдэрвэл тэр өдрийн өөрчлөлтүүдээ алдана. Хоббигийн аппликешнд энэ зүгээр. Захиалга авдаг аппликешнд тийм биш байж магадгүй.
• Сэргээх явцад аппликешн хэр удаан унтарч болох вэ? Жижиг мэдээллийн сан минутын дотор сэргээгддэг. Том нь хамаагүй удаан байж болно, шаардлагатай үед нь үүнийг урьдчилан мэдэх хэрэгтэй.

Ихэнх жижиг аппликешны хувьд өдөр бүрийн автомат нөөцлөлт, эрсдэлтэй өөрчлөлтийн өмнөх гараар нөөцлөлт сайн эхлэл. Мөнгө эсвэл эрүүл мэндийн мэдээлэлтэй аппликешнд илүү олон удаа нөөцлөх, эсвэл цэгт-цагийн сэргээлт (зөвхөн сүүлийн нөөцлөлт биш, дурын мөч руу сэргээх боломж)-тэй удирдаж буй мэдээллийн сан хэрэгтэй.

Алхам 2: Таны хостинг юу хийдгийг шалга

Олон удирдаж буй мэдээллийн сангийн үйлчилгээ үзүүлэгчид автомат нөөцлөлт хийдэг. Дараахийг олж мэд:

• Таны тарифт нөөцлөлт асаалттай юу, хэр олон удаа явдаг вэ?
• Хэр удаан хадгалдаг вэ?
• Цэгт-цагт сэргээж чадах уу, эсвэл зөвхөн өдрийн агшин дээр уу?
• Нөөцлөлтийг татаж авч чадах уу, эсвэл зөвхөн тэдний системд сэргээх үү?

Үйлчилгээ үзүүлэгчийн нөөцлөлт хэрэгтэй ч, мэдээллийн сантай адил нэг л эх сурвалжтай: данс. Данс хаагдах, түдгэлзүүлэх эсвэл төсөл устгагдвал нөөцлөлт нь ч бас алга болж магадгүй. Тийм учраас өөрийн хуулбартай байх хэрэгтэй.

Алхам 3: pg_dump-аар дамп хийх

pg_dump нь Postgres мэдээллийн санг файл руу экспортлодог. Тэр тогтвортой агшин зургийг уншдаг тул аппликешн ажиллаж байхад ч үргэлжлүүлж чадна.

Аппликешнд аль хэдийн байгаа холболтын мөрийг орчны хувьсагчаас ашигласан жишээ команд:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

Сонголтууд юу хийдэг вэ:

• --format=custom нь pg_restore-д уншигдах шахагдсан файл бичдэг, мөн хүснэгт тус тусаар нь хожим сэргээх боломж олгодог. Унших боломжтой .sql файл хүсвэл --format=plain ашигла.
• --no-owner нь эзэмшигчийн командуудыг орхиж, өөр мэдээллийн санд сэргээхэд хялбар болгодог.
• Файлын нэрэнд байгаа огноо нөөцлөлтүүдийг салгаж байлгана.

pg_dump-ийн хувилбар нь таны мэдээллийн сангийн Postgres хувилбартай тэнцүү эсвэл түүнээс шинэ байх ёстой. Хуучин pg_dump ажиллахаас татгалзаж магадгүй.

AI-аар бүтээж байгаа бөгөөд командын мөртэй ажиллахгүй бол иймэрхүү асууж болно:

Аппликешны мэдээллийн санг custom форматтай pg_dump ашиглан нөөцлө, файлын нэрэнд өнөөдрийн огноо оруул. Холболтын мөр эсвэл ямар ч нууцыг хэвлэж хараарай. Дууссан үед файлын нэр болон хэмжээг надад хэл.

Алхам 4: Автоматжуулах

Гарын нөөцлөлтийг хүмүүс мартдаг. Таны тохиргоо дэмждэг аливаа аргаар автоматжуул:

• Мэдээллийн сангийн үйлчилгээ үзүүлэгчийн хуваарьт нөөцлөлт, хэрэв санал болгодог бол.
• Хуваарьт ажил сервер эсвэл CI үйлчилгээ дээр, pg_dump ажиллуулж файлыг хадгалах газар байршуулдаг.
• Удирдаж буй нөөцлөлтийн үйлчилгээ, мэдээллийн сантай холбогддог.

Ямар ч сонгосон ч, нөөцлөлт бүтэлгүйтэхэд танд мэдэгдэх ёстой. Гурван сарын турш чимээгүйхэн бүтэлгүйтсэн нөөцлөлтийн ажил бол хамгийн түгээмэл аймшигт түүх.

Алхам 5: Хуулбарыг өөр газар хадгал

Эрдмийн дүрэм нь ихэвчлэн 3-2-1 гэж нэрлэгддэг: өгөгдлийн гурван хуулбар, хоёр өөр төрлийн хадгалалт дээр, нэг нь газраас гадуур. Жижиг аппликешны хувьд практик хувилбар нь:

• Амьд мэдээллийн сан
• Үйлчилгээ үзүүлэгчийн өөрийн автомат нөөцлөлт
• Өөр дансны объектын хадгалалтын бакет дэх таны өөрийн дамп

Мөн:

• Хандалтыг хязгаарла. Нөөцлөлтөд бүх хэрэглэгчийн өгөгдөл байдаг. Амьд мэдээллийн санд адил хандах хэрэгтэй.
• Хадгалах бодлого гарга. Жишээ нь хоёр долоо хоногийн өдөр тутмын, нэг жилийн сар бүрийн нөөцлөлт. Хуучин нөөцлөлтүүдийг санаатайгаар устга, мөн хувийн мэдээллийг хүсэлтээр устгахыг хууль шаардаж магадгүйг санаарай.
• Нөөцлөлтийг Git-д хэзээ ч оруулахгүй. Репозитори дахь дамп бол өгөгдөл задрах эрсдэл.

Алхам 6: Сэргээлтийг туршиж үз

Нөөцлөлт нь хамгийн сүүлийн амжилттай сэргээлт шиг л сайн. Хааяа, ядаж хэдэн сар тутамд, мөн нөөцлөлтийн процесст өөрчлөлт орсон бүрд:

1. Шинэ, хоосон мэдээллийн сан үүсгэ. Туршихдаа амьд мэдээллийн санг хэзээ ч дарж бичихгүй.
2. Хамгийн сүүлийн нөөцлөлтийг түүнд сэргээ:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

Энгийн .sql файлын хувьд psql "$TEST_DATABASE_URL" -f backup.sql ашигла.

1. Бүх хүснэгт байгааг шалгаж, мөрийн тоог амьд мэдээллийн сантай харьцуул, хамгийн сүүлийн хэдэн бичлэгийг хар.
2. Боломжтой бол аппликешний хуулбарыг түүн рүү заагаад нэвтэрч үз.
3. Сэргээлт хэр удаан үргэлжилснийг тэмдэглэ. Энэ бол таны бодит сэргээх хугацаа.

Алхам 7: Эрсдэлтэй өөрчлөлтийн өмнө нөөцөл

Дараахийн өмнө шинэ нөөцлөлт хий:

• Багана устгадаг эсвэл нэрийг нь өөрчилдөг мэдээллийн сангийн миграци ажиллуулахаас өмнө
• Багцаар өгөгдөл импортлохоос өмнө
• AI агентад өгөгдлийн загварт том өөрчлөлт хийлгэхээс өмнө
• Хуучин бичлэгүүдийг устгахаас өмнө

AI-аар бүтээсэн аппликешнд агент функцийн нэг хэсэг болгон хүснэгтийн бүтцийг өөрчилж болно. Checkpoint болон хувилбарын удирдлага нь таны кодыг буцаадаг, гэхдээ устгасан мөрийг сэргээдэггүй. Том өөрчлөлтийн өмнөх гучин секундын нөөцлөлт бол хямд даатгал.

Түгээмэл алдаанууд

• Git эсвэл кодын экспортыг нөөцлөлт гэж бодох. Тэдгээрт код байдаг, өгөгдөл байдаггүй.
• Сэргээлтийг хэзээ ч туршдаггүй. Олон нөөцлөлт хэрэгтэй үед л хоосон, дутуу эсвэл уншигдахгүй байдаг болж таарна.
• Нөөцлөлтийг мэдээллийн сантай адил дансанд хадгалах. Нэг компромисстой эсвэл хаагдсан данс хоёуланг нь алдана.
• Байршуулсан файлуудыг мартах. Мэдээллийн сан файлын замыг хадгалдаг; зураг нь хадгалалтад байдаг.
• Нөөцлөлтийн скриптэд нууцыг үлдээх. Холболтын мөрийг скриптийн текстээс биш орчны хувьсагчаас унш. Үүний тухай API түлхүүрээ хэрхэн аюулгүй байлгах вэ гэдгийг үз.

Нөөцлөлт ба Mythex

Mythex төслүүд тусдаа Postgres мэдээллийн сантай байж болох бөгөөд түүний холболтын мэдээлэл ажлын орчинд болон нийтлэгдсэн аппликешнд оруулагддаг. Mythex-ийн баримт бичигт мэдээллийн сангийн нөөцлөлт эсвэл сэргээх функцийг тайлбарладаггүй тул өөрийн нөөцлөлтийг төлөвлө: агентаас дамп хийлгэж, татаж аваад, аюулгүй газар хадгал, ялангуяа том өөрчлөлтийн өмнө. Төслийн экспорт (Pro) нь код агуулдаг, нууц болон node_modules оруулдаггүй; мэдээллийн сангийн мөрүүдийг агуулдаггүй. Дэлгэрэнгүйг баримт бичгийн Database болон Data ownership хэсгээс үз. Мэдээллийн сангийн талаар илүү мэдэхийн тулд Postgres гэж юу вэ гэдгийг унш.

Нөөцлөлтийн хяналтын хуудас

• Хэр их өгөгдлөө алдаж болох, хэр удаан унтарч болохоо шийдсэн
• Мэдээллийн сангийн хостинг ямар автомат нөөцлөлт өгдөгийг шалгасан
• Өөрийн дамп хуваарийн дагуу явдаг, бүтэлгүйтэхэд сэрэмжлүүлдэг
• Хуулбарууд мэдээллийн сангаас тусдаа, хандалт хязгаарлагдсан газар хадгалагдсан
• Хадгалах бодлого бичгээр тодорхойлогдсон
• Байршуулсан файлуудыг мэдээллийн сантай адил нөөцөлдөг
• Сэргээлтийг хоосон мэдээллийн санд туршсан, мөрийн тоог шалгасан
• Эрсдэлтэй өөрчлөлт бүрийн өмнө нөөцлөлт хийдэг

Асуултууд