როგორ შევინახოთ აპის მონაცემთა ბაზის სარეზერვო ასლი (და რეალურად აღვადგინოთ)

მონაცემთა ბაზის სარეზერვო ასლი ნიშნავს, რომ ბაზას გრაფიკით ექსპორტს უკეთებ ფაილში (Postgres-ისთვის სტანდარტული ინსტრუმენტია pg_dump), ასლებს ბაზისგან განცალკევებით ინახავ და რეგულარულად აღადგენ ცარიელ ბაზაში, რომ დარწმუნდე, რომ ისინი მუშაობს. ყოველი რისკიანი ცვლილების წინ გააკეთე დამატებითი ასლი. შენი კოდის სარეზერვო ასლი, იქნება ეს GitHub-ის რეპოზიტორია თუ ექსპორტი, შენს მონაცემებს არ მოიცავს.

ეს გზამკვლევი განკუთვნილია მცირე აპის მფლობელებისთვის, რომლებსაც სურთ, რომ აპის დაკარგვაზე აღარ იდარდონ. მაგალითებში Postgres-ია გამოყენებული, რადგან AI-ით აშენებული აპების უმეტესობა მას იყენებს, მაგრამ პრინციპები ნებისმიერ მონაცემთა ბაზას ეხება.

რა უნდა დაფაროს სარეზერვო ასლმა

აპი მხოლოდ მონაცემთა ბაზა არ არის. იცოდე, რომელი ნაწილი რომელი ასლით იცავს.

მონაცემები არის ის ნაწილი, რომლის აღდგენაც შეუძლებელია. კოდის გადაწერა შეიძლება, პარამეტრების თავიდან შეყვანა შეიძლება, მაგრამ შენი მომხმარებლების შეკვეთები ვერ აღდგება.

ნაბიჯი 1: განსაზღვრე, რამდენი მონაცემის დაკარგვა შეგიძლია

ორი კითხვა განსაზღვრავს შენს სარეზერვო გეგმას:

• რამდენი ბოლო მონაცემის დაკარგვა შეგიძლია? თუ დღეში ერთხელ ქმნი ასლს და ბაზა საღამოს გაფუჭდა, იმ დღის ცვლილებებს დაკარგავ. პატარა ჰობი აპისთვის ეს მისაღებია. აპისთვის, რომელიც შეკვეთებს იღებს, შესაძლოა არა.
• რამდენ ხანს შეიძლება აპი იყოს გათიშული აღდგენის დროს? პატარა ბაზა წუთებში აღდგება. დიდი ბაზა გაცილებით მეტ დროს მოითხოვს, და ეს უნდა იცოდე მანამ, სანამ არ დაგჭირდება.

მცირე აპებისთვის გონივრული დასაწყისია ყოველდღიური ავტომატური ასლი და ხელით შექმნილი ასლი რისკიან ცვლილებამდე. აპები, სადაც ფული ან ჯანმრთელობის მონაცემებია ჩართული, უფრო ხშირ ასლებს ან მართულ მონაცემთა ბაზას უნდა მოითხოვდნენ, მათ შორის point-in-time recovery-ს (შესაძლებლობას, აღადგინო ბაზა ნებისმიერ მომენტამდე და არა მხოლოდ ბოლო ასლამდე).

ნაბიჯი 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-ით აშენებ და ბრძანებათა ხაზთან მუშაობა არ გინდა, შეგიძლია ასე სთხოვო:

შექმენი აპის მონაცემთა ბაზის ასლი pg_dump-ით custom ფორმატში, ფაილის სახელში დღევანდელი თარიღით. არ დაბეჭდო კავშირის სტრიქონი ან რაიმე საიდუმლო. დამიწერე ფაილის სახელი და ზომა, როცა დასრულდება.

ნაბიჯი 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-ით აშენებულ აპში აგენტმა შეიძლება ცხრილების სტრუქტურა შეცვალოს ფუნქციის ნაწილად. Checkpoints-ები და ვერსიების კონტროლი შენს კოდს აბრუნებს უკან, მაგრამ წაშლილ ჩანაწერებს ვერ დააბრუნებს. ოცდაათწამიანი ასლი დიდ ცვლილებამდე იაფი დაზღვევაა.

გავრცელებული შეცდომები

• Git-ის ან კოდის ექსპორტის სარეზერვო ასლად ჩათვლა. ეს შეიცავს კოდს და არა მონაცემებს.
• აღდგენის არასდროს ტესტირება. ბევრი სარეზერვო ასლი გამოდის ცარიელი, ნაწილობრივი ან წაუკითხავი მაშინ, როცა გჭირდება.
• ასლების შენახვა იმავე ანგარიშზე, სადაც ბაზაა. ერთი დატყვევებული ან დახურული ანგარიში ორივეს კარგავს.
• ატვირთული ფაილების დავიწყება. ბაზა ფაილის გზას ინახავს; თავად სურათი საცავში ცხოვრობს.
• საიდუმლოებების დატოვება სარეზერვო სკრიპტებში. კავშირის სტრიქონი გარემოს ცვლადიდან წაიკითხე და არასდროს სკრიპტის ტექსტიდან. იხილე როგორ შევინახოთ API გასაღებები უსაფრთხოდ.

სარეზერვო ასლები და Mythex

Mythex-ის პროექტებს შეიძლება ჰქონდეთ გამოყოფილი Postgres ბაზა, და მისი კავშირის დეტალები ინექტირდება სამუშაო სივრცეში და გამოქვეყნებულ აპში. Mythex-ის დოკუმენტაცია ბაზის სარეზერვო ასლის ან აღდგენის შესაძლებლობას არ აღწერს, ამიტომ საკუთარი გეგმა გაითვალისწინე: სთხოვე აგენტს დამპის შექმნა, ჩამოტვირთე იგი და შეინახე უსაფრთხო ადგილას, განსაკუთრებით დიდი ცვლილებების წინ. პროექტის ექსპორტი (Pro) შეიცავს შენს კოდს, საიდუმლოებებისა და node_modules-ის გარეშე; ის ბაზის ჩანაწერებს არ შეიცავს. იხილე Database და Data ownership დოკუმენტაციაში. მონაცემთა ბაზის შესახებ მეტი იხილე რა არის Postgres.

სარეზერვო ასლის ჩეკლისტი

• გადაწყვეტილია, რამდენი მონაცემის დაკარგვა შეგიძლია და რამდენ ხანს შეგიძლია იყო გათიშული
• შემოწმებულია, რა ავტომატურ ასლებს გთავაზობს მონაცემთა ბაზის ჰოსტი
• შენი საკუთარი დამპი გრაფიკით მუშაობს და წარუმატებლობა გაფრთხილებს
• ასლები შენახულია ბაზისგან განცალკევებით, შეზღუდული წვდომით
• შენახვის პოლიტიკა დაწერილია
• ატვირთული ფაილები ასლდება ბაზასთან ერთად
• აღდგენა გატესტილია ცარიელ ბაზაში, ჩანაწერების რაოდენობა შემოწმებულია
• სარეზერვო ასლი გაკეთებულია ყოველი რისკიანი ცვლილების წინ

კითხვები