Ինչպես պահուստավորել ձեր հավելվածի տվյալների բազան (և իրոք վերականգնել այն)

Ձեր հավելվածի տվյալների բազան պահուստավորելու համար արտահանեք այն ֆայլի մեջ ըստ ժամանակացույցի (Postgres-ի համար ստանդարտ գործիքը pg_dump-ն է), պահեք պատճեններ բազայից առանձին տեղում և պարբերաբար վերականգնեք մեկը դատարկ տվյալների բազայի մեջ՝ ապացուցելու համար, որ այն աշխատում է։ Ռիսկային փոփոխությունից առաջ արեք լրացուցիչ պահուստ։ Ձեր կոդի պահուստը, լինի դա GitHub-ի պահոց, թե արտահանում, տվյալները չի ներառում։

Ուղեցույցը նախատեսված է նրանց համար, ովքեր աշխատեցնում են փոքր հավելված և ցանկանում են դադարել անհանգստանալ դրա կորստի համար։ Օրինակներում օգտագործվում է Postgres, քանի որ AI-ով կառուցված հավելվածների մեծ մասն օգտագործում է այն, բայց սկզբունքները կիրառելի են ցանկացած տվյալների բազայի համար։

Ինչ պետք է ծածկի պահուստը

Հավելվածը ավելին է, քան իր տվյալների բազան։ Իմացեք, թե յուրաքանչյուր պահուստ ո՞ր մասն է պաշտպանում։

Տվյալները այն մասն են, որը չի կարելի վերստեղծել։ Կոդը կարելի է ինքնուրույն վերագրել, կարգավորումները՝ նորից մուտքագրել, բայց ձեր հաճախորդների պատվերները հնարավոր չէ վերականգնել։

Քայլ 1. Որոշեք, թե որքան կարող եք կորցնել

Երկու հարց է որոշում ձեր պահուստավորման պլանը.

• Որքա՞ն վերջին տվյալ կարող եք թույլ տալ կորցնել։ Եթե պահուստավորում եք օրը մեկ անգամ, և բազան երեկոյան է խափանվում, կորցնում եք այդ օրվա փոփոխությունները։ Հոբբի հավելվածի համար դա նորմալ է, իսկ պատվերներ ընդունող հավելվածի համար՝ միգուցե ոչ։
• Որքա՞ն ժամանակ կարող է հավելվածը անջատված մնալ մինչև վերականգնումը։ Փոքր բազան վերականգնվում է րոպեների ընթացքում։ Մեծը կարող է շատ ավելի երկար տևել, և դա պետք է իմանաք դեռ մինչ այն անհրաժեշտ լինելը։

Փոքր հավելվածների մեծ մասի համար օրական ավտոմատ պահուստը և ռիսկային փոփոխություններից առաջ ձեռքով պահուստը ողջամիտ սկիզբ են։ Փող կամ առողջական տվյալներ ներառող հավելվածները պետք է ավելի հաճախ պահուստավորեն, կամ օգտագործեն կառավարվող տվյալների բազա՝ point-in-time վերականգնման հնարավորությամբ (այսինքն՝ վերականգնել ցանկացած պահի վիճակը, ոչ միայն վերջին պահուստը)։

Քայլ 2. Ստուգեք, թե ինչ է անում ձեր հոսթը

Շատ կառավարվող տվյալների բազայի մատակարարներ ինքնուրույն ստեղծում են պահուստներ։ Պարզեք.

• Արդյո՞ք պահուստավորումը միացված է ձեր պլանում, և որքան հաճախ է այն աշխատում։
• Որքա՞ն ժամանակ են պահվում։
• Կարո՞ղ եք վերականգնել ըստ ժամանակային կետի, թե միայն օրական պատկերի։
• Կարո՞ղ եք ներբեռնել պահուստը, թե միայն վերականգնել նրանց համակարգում։

Մատակարարի պահուստները օգտակար են, բայց դրանք ունեն ընդհանուր կետ ձախողման հետ՝ ձեր տվյալների բազայի հետ՝ հաշիվը։ Եթե հաշիվը փակվի, կասեցվի կամ նախագիծը ջնջվի, պահուստները կարող են նույնպես կորչել։ Դրա համար ձեզ պետք է նաև ձեր սեփական պատճենը։

Քայլ 3. Արեք dump pg_dump-ով

pg_dump-ը Postgres-ի տվյալների բազան արտահանում է ֆայլի մեջ։ Այն կարդում է հետևողական նկարահանում (snapshot), այնպես որ հավելվածը կարող է շարունակել աշխատել, մինչ այն արտահանում է։

Տիպիկ հրաման՝ օգտագործելով այն կապի տողը, որ ձեր հավելվածն արդեն ունի միջավայրի փոփոխականում.

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-ով եք կառուցում և չեք ուզում դիպչել հրամանային տողին, կարող եք խնդրել.

Ստեղծիր հավելվածի տվյալների բազայի պահուստը pg_dump-ով՝ custom ձևաչափով, ֆայլի անվան մեջ՝ այսօրվա ամսաթվով։ Մի տպիր կապի տողը կամ որևէ գաղտնիք։ Երբ ավարտես, ասա ինձ ֆայլի անունը և չափը։

Քայլ 4. Ավտոմատացրեք

Ձեռքով պահուստները մոռացվում են։ Ավտոմատացրեք դրանք այն միջոցներով, որ աջակցում է ձեր կարգավորումը.

• Ձեր տվյալների բազայի մատակարարի ժամանակացույցված պահուստները, եթե այն առաջարկում է։
• Ժամանակացույցված աշխատանք սերվերի կամ CI ծառայության վրա, որը աշխատեցնում է pg_dump-ը և վերբեռնում ֆայլը պահոց։
• Հոսթավորված պահուստային ծառայություն, որը միանում է ձեր տվյալների բազային։

Անկախ նրանից, թե ինչ եք ընտրում, կարգավորեք այնպես, որ այն ազդանշան տա, երբ պահուստը ձախողվում է։ Պահուստային աշխատանք, որը անաղմուկ ձախողվել է երեք ամիս շարունակ, դասական սարսափ պատմություն է։

Քայլ 5. Պահեք պատճենները այլ տեղ

Կանոնը հաճախ կոչվում է 3-2-1. երեք պատճեն ձեր տվյալների, երկու տարբեր տեսակի պահոցում, և մեկ պատճեն՝ աշխարհագրորեն այլ տեղում։ Փոքր հավելվածի համար գործնական տարբերակն է.

• Կենդանի տվյալների բազան
• Մատակարարի սեփական ավտոմատ պահուստները
• Ձեր սեփական dump-երը առանձին պահոցում, օրինակ՝ օբյեկտների պահոցում այլ հաշվում

Եվս.

• Սահմանափակեք հասանելիությունը։ Պահուստը պարունակում է բոլոր օգտատերերի տվյալները։ Վարվեք դրա հետ, ինչպես կենդանի տվյալների բազայի հետ։
• Ունեցեք պահպանման քաղաքականություն։ Օրինակ՝ օրական պահուստներ երկու շաբաթ և ամսական՝ մեկ տարի։ Հին պահուստները ջնջեք միտումնավոր, և հիշեք, որ գաղտնիության օրենքները կարող են պահանջել անձնական տվյալները ջնջել հարցումով։
• Երբեք մի մտցրեք պահուստները Git-ում։ Պահոցում գտնվող dump-ը տվյալների արտահոսքի պոտենցիալ աղբյուր է։

Քայլ 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 փաստաթղթերը չեն նկարագրում տվյալների բազայի պահուստավորման կամ վերականգնման գործառույթ, այնպես որ պլանավորեք սեփականը։ Խնդրեք գործակալին անել dump, ներբեռնեք այն և պահեք անվտանգ տեղում, հատկապես մեծ փոփոխություններից առաջ։ Նախագծի արտահանումը (Pro) պարունակում է ձեր կոդը, առանց գաղտնիքների և node_modules-ի, բայց ոչ տվյալների բազայի տողերը։ Տե՛ս Database և Data ownership փաստաթղթերում։ Տվյալների բազայի մասին ավելին իմանալու համար կարդացեք what is Postgres։

Պահուստների ստուգաթերթ

• Որոշված է, թե որքան տվյալ կարող եք թույլ տալ կորցնել և որքան ժամանակ կարող եք անջատված լինել
• Ստուգված է, թե ինչ ավտոմատ պահուստներ է տրամադրում ձեր տվյալների բազայի հոսթը
• Ձեր սեփական dump-ն աշխատում է ըստ ժամանակացույցի, և ձախողումները ազդանշան են տալիս
• Պատճենները պահվում են տվյալների բազայից առանձին, սահմանափակ հասանելիությամբ
• Պահպանման քաղաքականությունը գրված է
• Վերբեռնված ֆայլերը պահուստավորված են տվյալների բազայի հետ միասին
• Վերականգնումը փորձարկված է դատարկ տվյալների բազայի մեջ, տողերի քանակը ստուգված է
• Պահուստ է արված յուրաքանչյուր ռիսկային փոփոխությունից առաջ

Հարցեր