მონაცემთა ბაზის backup და აღდგენა: dump, რომელიც ბრუნდება

მონაცემთა ბაზის backup ფაილების backup-ისგან სხვაგვარად ფუჭდება. ნახევრად გადაწერილი სამყაროს ფაილი აშკარად გატეხილია - ის არ იტვირთება და ერთ წუთში იგებ. ნახევრად თანმიმდევრული dump სუფთად აღდგება და ჩუმად არასწორია: orders ცხრილში არის რიგები, რომლებიც order_items ცხრილში არ არის, foreign key არაფერზე მიუთითებს და აპლიკაცია მუშაობს მანამ, სანამ ვინმე ისეთ გვერდს არ გახსნის, რომელიც ორივეს ეხება. ამის თავიდან ასაცილებელი ინსტრუმენტები არსებობს და ერთი გადამრთველი ღირს.

მოკლე ვერსია: გამოიყენე pg_dump PostgreSQL-ისთვის და mongodump MongoDB-სთვის, არასოდეს გაუკეთო ფაილური ასლი მოქმედი ბაზის მონაცემთა საქაღალდეს, dump მანქანის გარეთ ჩაწერე და გრაფიკით აღადგინე scratch ბაზაში, რომ იცოდე, მუშაობს. ქვემოთ ყველაფერი დეტალებია, იმ გადამრთველების ჩათვლით, რომლებსაც მნიშვნელობა აქვს, იმ რამეების ჩათვლით, რასაც dump უკან ტოვებს, და იმის ჩათვლით, რა უნდა გააკეთო, როცა ერთი საათის ჩაწერების დაკარგვა დაუშვებელია.

რატომ არ არის მოქმედი ბაზის ფაილური ასლი backup#

მონაცემთა ბაზა ფაილების ნაკრებია, რომლებიც მხოლოდ ერთ მომენტში აქვთ ერთად აზრი. სანამ ის მუშაობს, გვერდები იწერება, write-ahead log მონაცემთა ფაილებს წინ უსწრებს და ის, რასაც აპლიკაცია დადასტურებულად თვლის, ნაწილობრივ ჯერ კიდევ მეხსიერებაშია. tar ამ საქაღალდეს გადის, ფაილ A-ს იღებს 03:00:01-ზე და ფაილ Z-ს 03:04:12-ზე, და შედეგი არის ფაილების ნაკრები, რომლებიც არასოდეს არსებობდნენ ერთად.

PostgreSQL-ისთვის ამის გამოსწორება ზოგჯერ შესაძლებელია და ყოველთვის უსიამოვნო. MongoDB-სთვის WiredTiger ძრავით ეს ჩვეულებრივ უბრალოდ დაზიანებული მონაცემთა საქაღალდეა. „საქაღალდეს გავუკეთე backup“ ყველაზე გავრცელებული გზაა, რომლითაც backup აღმოჩნდება, რომ backup არ ყოფილა.

არსებობს სამი კანონიერი მიდგომა და ისინი განსხვავებულ კითხვებს პასუხობენ:

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

PostgreSQL: dump, რომელსაც შეგიძლია ენდო#

pg_dump ხსნის ერთ ტრანზაქციას repeatable-read იზოლაციის დონეზე და მთელ ბაზას ამ ერთი snapshot-იდან კითხულობს. ფაილში ყველაფერი ერთი მომენტისაა, რამდენ ხანსაც არ უნდა გაგრძელდეს dump და რასაც არ უნდა აკეთებდეს აპლიკაცია ამ დროს. ეს არის თვისება, რისთვისაც იხდი.

$ export PGPASSWORD=... # better: use ~/.pgpass, see below$ pg_dump --host=db.example.net --port=5432 --username=app \    --format=custom --no-owner --no-privileges \    --file=/backups/app-$(date +%F).dump app

ორი რამ, რასაც pg_dump არ შეიცავს და ორივე აღდგენის დღეს გვკბენს:

• როლები, პაროლები და tablespace-ები. ისინი მთელი კლასტერისაა და არა ერთი ბაზის. ცალკე გააკეთე dump pg_dumpall --globals-only > globals.sql-ით და ფაილი dump-ის გვერდით შეინახე. მის გარეშე, სუფთა სერვერზე აღდგენა ბაზას გვაძლევს, რომლის აპლიკაციის მომხმარებელი არ არსებობს.
• თავად extension-ები. dump შეიცავს CREATE EXTENSION postgis;-ს, მაგრამ არა PostGIS-ს. სამიზნე სერვერს extension უკვე ხელმისაწვდომი უნდა ჰქონდეს, თორემ აღდგენა იქვე გაჩერდება.

მოწმობები ბრძანების ხაზიდან მოარიდე - იქ აკრეფილი ყველაფერი მანქანის ყველა სხვა მომხმარებლისთვის ხილულია პროცესების სიაში. ამის ნაცვლად გამოიყენე პაროლის ფაილი:

db.example.net:5432:app:app_user:the-password

ერთი ვერსიის წესი, რომელიც დასამახსოვრებელია: გაუშვი pg_dump და pg_restore binary-ები ვერსიიდან, რომელიც სერვერზე, რომელთანაც ლაპარაკობ, სულ მცირე ისეთივე ახალია. ძველი pg_dump ახალ სერვერთან მუშაობაზე უარს იტყვის, ხოლო უფრო ახალი მთავარი ვერსიით გაკეთებული dump ყოველთვის არ ჩაიტვირთება უფრო ძველში. როცა მთავარ ვერსიებს შორის გადადიხარ, გააკეთე dump ახალი ვერსიის ინსტრუმენტებით.

PostgreSQL: უკან დაბრუნება#

აღადგინე ცარიელ ბაზაში და არასოდეს ცოცხალზე, რომლის dump-იც ჯერ არ გაგიკეთებია.

$ createdb -h db.example.net -U app app_restore$ pg_restore --host=db.example.net --username=app --dbname=app_restore \    --no-owner --no-privileges --jobs=4 /backups/app-2026-09-21.dump

--jobs არის გადამრთველი, რომელიც ნებისმიერ მოზრდილ ბაზაზე საათს თხუთმეტ წუთად აქცევს; ის ცხრილებს ტვირთავს და ინდექსებს აგებს პარალელურად და custom ან directory არქივებთან მუშაობს. ერთი ან ორი vCPU-ს მქონე გეგმაზე -j 2-ს მიღმა მოგება ცოტაა, რადგან იმავე შეზღუდვით ხარ შეზღუდული, რითაც ყველაფერი დანარჩენი.

სასარგებლო ვარიაციები:

• არსებული ბაზის ადგილზე ჩანაცვლება: დაამატე --clean --if-exists. ეს ორჯერ წაიკითხე, სანამ პროდაქშენის სახელზე გაუშვებ. ის ობიექტებს ხელახლა შექმნამდე შლის და თუ dump-ს ცხრილი აკლია, ეს ცხრილი ახლა აღარ არსებობს.
• ერთი ცხრილის აღდგენა: pg_restore -d app_restore -t orders app.dump. მასთან დაკავშირებული ინდექსები და შეზღუდვები ავტომატურად არ შედის, ამიტომ ჯერ შეამოწმე pg_restore -l app.dump-ით - ის ბეჭდავს შინაარსის ცხრილს, რომელიც შეგიძლია დაარედაქტირო და -L-ით უკან მიაწოდო ზუსტი შერჩევითი აღდგენისთვის.
• უბრალო SQL dump (-Fp, ან ნებისმიერი, რაც pg_dumpall-მა გამოიტანა) საერთოდ pg_restore-ით არ აღდგება. ეს სკრიპტია: psql -d app_restore -f app.sql. დაამატე -v ON_ERROR_STOP=1, თორემ ის უშფოთველად გაივლის წარუმატებლობას და არაფერს გეტყვის.

ownership-სა და extension-ების კომენტარების შესახებ გაფრთხილებებს მოელი სუფთა აღდგენაშიც; როცა --no-owner გამოიყენე, ისინი ხმაურია. ხმაური არ არის არანულოვანი exit code ან ნებისმიერი ხაზი, რომელიც შეიცავს ERROR:-ს. გამოტანა ფაილში გადაიტანე და წაიკითხე.

MongoDB: mongodump და mongorestore#

ეს ინსტრუმენტები აღარ არის სერვერის პაკეტის ნაწილი - ისინი MongoDB Database Tools-ის სახით მოდის და ცალკე ისმება. შეამოწმე mongodump --version-ით, სანამ ისინი გჭირდება ღამის ორ საათზე.

$ mongodump --uri="mongodb://app:PASSWORD@db.example.net:27017/?authSource=admin" \    --db=app --gzip --archive=/backups/app-$(date +%F).gz

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

თანმიმდევრულობის გაფრთხილება მნიშვნელოვანი ნაწილია. Standalone mongod-ზე mongodump კოლექციებს სათითაოდ კითხულობს snapshot-ის გარეშე, ამიტომ ბაზის dump, რომელშიც ჩაწერა მიმდინარეობს, კოლექციებს შორის თანმიმდევრულობის გარანტიას არ იძლევა. Replica set-ზე --oplog იწერს ოპერაციებს, რომლებიც dump-ის დროს მოხდა, რათა mongorestore --oplogReplay-მ ისინი ერთ წერტილამდე გადაატაროს:

$ mongodump --uri="mongodb://...@host:27017/?authSource=admin" \    --oplog --gzip --archive=/backups/full-$(date +%F).gz

თუ standalone ინსტანციაზე ხარ და მონაცემები მნიშვნელოვანია, ან გააკეთე dump მშვიდ ფანჯარაში, ან შეეგუე, რომ კოლექციებს შორის თანმიმდევრულობა გარანტირებული არ არის და აპლიკაცია ისე დააპროექტე, რომ ამას მნიშვნელობა არ ჰქონდეს.

აღდგენა:

$ mongorestore --uri="mongodb://app:PASSWORD@db.example.net:27017/?authSource=admin" \    --gzip --archive=/backups/app-2026-09-21.gz \    --nsFrom='app.*' --nsTo='app_restore.*'

--nsFrom და --nsTo წყვილი არის MongoDB-ის ექვივალენტი scratch ბაზაში აღდგენისა: იგივე მონაცემები სხვა სახელით მოდის, პროდაქშენის გვერდით, სადაც დოკუმენტებს დათვლი და აპლიკაციის ასლს მიუთითებ. სხვა გადამრთველები, რომლებიც ცოდნად ღირს: --drop აღდგენამდე თითოეულ კოლექციას შლის (დესტრუქციულია, იგივე გაფრთხილება, რაც ზემოთ --clean-ზე), --nsInclude='app.orders' ერთ კოლექციას აღადგენს, ხოლო --restoreDbUsersAndRoles მომხმარებლებსა და როლებს აბრუნებს, როცა ბაზას, რომელსაც ისინი ჰქონდა, აღადგენ.

Mongo-ს ვერიფიკაცია გრძნობის ნაცვლად shell-ის ერთი ხაზია:

db.getSiblingDB("app_restore").orders.countDocuments()db.getSiblingDB("app_restore").stats()

შეადარე პროდაქშენს. თუ რიცხვები ახლოსაა, მაგრამ არ ემთხვევა, ასე გამოიყურება არათანმიმდევრული dump და ეს არის მიზეზი, რატომაც replica set-ის შესახებ ზემოთ მოცემული კითხვა გაინტერესებს. Postgres თუ MongoDB ფარავს ამ ორს შორის უფრო ფართო არჩევანს, თუ ჯერ კიდევ წყვეტ.

ბაზის სლოტი, რომელიც შენს თამაშის ან აპის გეგმას მოჰყვა#

თამაშის გეგმა ერთ ბაზის სლოტს შეიცავს, ხოლო app და web ხაზები ორს. ისინი იქმნება პანელში გენერირებული host-ით, მომხმარებლითა და პაროლით და იმართება phpMyAdmin-ით ერთჯერადი შესვლის ტოკენით, რომელიც სამოცი წამის შემდეგ იწურება. backup-ისთვის გამოიყენე მისი Export ჩანართი: აირჩიე მთელი ბაზა, აირჩიე SQL და შეკუმშე.

ორი ლიმიტი, რომელიც უნდა იცოდე, სანამ მას დაეყრდნობი. ბრაუზერით ექსპორტი რამდენიმე ასეულ მეგაბაიტამდე კარგია და მის მიღმა უსიამოვნოა, რადგან ჩამოტვირთვა მოძრაობაში გენერირდება და გაწყვეტილი კავშირი თავიდან დაწყებას ნიშნავს. იმპორტს უფრო მკაცრი ლიმიტი აქვს: ატვირთვის ზომა, რომელსაც ინტერფეისი იღებს. dump, რომელიც სუფთად ექსპორტირდება, შეიძლება იმპორტზე უარი თქვას და ჩვეულებრივი გამოსწორებაა მისი გაყოფა ან shell-იდან აღდგენა. phpMyAdmin-ის იმპორტი და ექსპორტი ამ დიალოგის პარამეტრებს სათითაოდ გადის.

გამოყოფილი ბაზების ჰოსტინგის ხაზი განსხვავებულია: PostgreSQL და MongoDB, ყოველ სერვერზე გენერირებული superuser პაროლი, პირდაპირი წვდომა გეგმის host-სა და პორტზე. ეს ნიშნავს, რომ ზემოთ მოყვანილი ბრძანების ხაზის ინსტრუმენტები მასთან ზუსტად ისე მუშაობს, როგორც დაწერილია, რაც მთავარი პრაქტიკული მიზეზია, რატომაც მზარდი ბაზა სლოტიდან საკუთარ გეგმაზე უნდა გადაიტანო.

dump-ის მანქანის გარეთ გატანა#

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

ნიმუში, რომელიც პანელზე მუშაობს, არის ორი სისტემის ერთმანეთზე დაწყობა:

1. განრიგი წერს dump-ს სერვერის საკუთარ საქაღალდეში, backup ამოცანამდე რამდენიმე წუთით ადრე.
2. backup ამოცანა საქაღალდეს არქივებს, dump-ის ჩათვლით, და არქივი იმ მანქანის გარეთ ინახება, რომელსაც იცავს.
3. კვირაში ერთხელ ერთ-ერთ ამ არქივს ჩამოტვირთავ სადმე, რაც შენი ჰოსტისგან დამოუკიდებელია.

VDS-ზე ან ნებისმიერ ადგილას, სადაც cron გაქვს, იგივე ერთი ხაზითა და როტაციით:

0 4 * * * pg_dump -Fc -f /backups/app-$(date +\%F).dump app && \  find /backups -name 'app-*.dump' -mtime +14 -delete

გაითვალისწინე გაექსკეიპებული % - გაუექსკეიპებელი cron ბრძანებას პირველზე ჭრის, რაც კლასიკური მიზეზია, რის გამოც backup ამოცანა ჩუმად არაფერს გამოიმუშავებს. შეამოწმე, რომ ფაილი არსებობს და ზომა დამაჯერებელია მეორე დილას და არა სამ თვეში. ამ ამოცანების თანმიმდევრობა და დრო პანელზე მოცემულია ამოცანებში, რომლებიც ღირს დაგეგმვად.

როცა ერთი საათის დაკარგვა დაუშვებელია#

ღამის dump-ები ნიშნავს, რომ 23:00-ზე მომხდარი ჩავარდნა დღეს კარგავს. თუ ეს ნამდვილად დაუშვებელია - მაღაზია, სალარო წიგნი, ყველაფერი, სადაც რიგები ფულია - გჭირდება უწყვეტი დაარქივება და ის ცვლის, რა უნდა გაუშვა.

PostgreSQL-ისთვის ეს არის point-in-time recovery: დააყენე archive_mode = on და archive_command, რომელიც ყოველ დასრულებულ write-ahead log სეგმენტს უსაფრთხო ადგილას აკოპირებს, პერიოდულად გააკეთე base backup pg_basebackup-ით, და აღსადგენად აღადგინე base backup და სერვერს მიეცი საშუალება, ლოგები recovery_target_time-მდე გაიმეოროს, რომელსაც შენ ირჩევ. ის გაძლევს ნებისმიერ წამს base backup-სა და ბოლო დაარქივებულ სეგმენტს შორის. ასევე საჭიროებს როლს REPLICATION ატრიბუტით, ადგილს სეგმენტებისთვის და საკმარის დისციპლინას, რომ შეამჩნიო, როცა დაარქივება წყდება - წარუმატებელი archive_command მონაცემთა საქაღალდეს გაუგზავნელი ლოგებით ავსებს, სანამ დისკი არ გაქრება.

MongoDB-სთვის ექვივალენტია replica set პლუს რეგულარული --oplog dump-ები, და პრაქტიკული ქვედა ზღვარი არის, რამდენად შორს აღწევს oplog-ის ფანჯარა: თუ შენი oplog ექვსი საათის ოპერაციებს ინახავს, შეგიძლია აღდგე ბოლო dump-იდან ექვს საათში ნებისმიერ წერტილამდე და არა უფრო შორს.

ორივეს მანქანა სჭირდება, რომელსაც აკონტროლებ და არა სლოტი. ეს არის გულწრფელი არგუმენტი VDS-ის სასარგებლოდ: არა წარმადობა, არამედ შესაძლებლობა, დაარქივების ბრძანება გაუშვა და მისი გამოტანა იქ შეინახო, სადაც შენ წყვეტ. სანამ ამას ააგებ, დარწმუნდი, რომ მოთხოვნა ნამდვილია, რადგან ოპერაციული ფასი მუდმივია და ღამის dump, რომელიც ნამდვილად შემოწმებულია, სჯობს PITR-ს, რომელიც არავის გამოუცდია.

დაამტკიცე, რომ აღდგენა მუშაობს#

ზემოთ სექციების მთელი აზრი ფაილია. ფაილი backup არ არის, სანამ ის ისევ ბაზა არ გახდება.

1. შექმენი ცარიელი ბაზა რეალურის გვერდით, ან სხვა სახელის მქონე namespace.
2. აღადგინე მასში იმავე ბრძანებით, რომელსაც ინციდენტში გამოიყენებდი. გაზომე დრო.
3. დათვალე რიგები სამ ყველაზე მნიშვნელოვან ცხრილში და შეადარე პროდაქშენს.
4. თუ შეგიძლია, აპლიკაციის ასლი მიუთითე და გახსენი გვერდი, რომელიც ყველაზე მეტ join-ს ეხება.
5. წაშალე.

გააკეთე ეს კვარტალში ერთხელ და backup გაქვს. გამოტოვე და ფაილი გაქვს. სრული სავარჯიშო, იმ რიცხვების გაზომვის ჩათვლით, რასაც ის იძლევა, და იმის, რა ტყდება ხშირად, არის აღდგენის შემოწმება სანამ გჭირდება-ში. თუ შენი აღდგენა სქემას მოიცავს, რომელიც dump-ის გაკეთების შემდეგ წინ წავიდა, წაიკითხე ასევე მიგრაციები downtime-ის გარეშე, რადგან ძველი მონაცემების ახალი კოდის ქვეშ აღდგენა ცუდი დღის საკუთარი კატეგორიაა.

FAQ#

შემიძლია უბრალოდ დავაკოპირო ბაზის ფაილები, სანამ ის მუშაობს?

არა. ფაილები ერთად თანმიმდევრულია მხოლოდ ერთ მომენტში და რამდენიმე წუთში გაკეთებული ასლი რამდენიმე მომენტს იღებს. გამოიყენე pg_dump ან mongodump, ან გააჩერე ბაზა, სანამ საქაღალდეს დააკოპირებ. გაჩერებული ბაზის snapshot სრულიად კარგი backup-ია; მოქმედის ასლი - არა.

რამდენად ხშირად უნდა გავაკეთო dump?

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

შეიცავს თუ არა ჩემი სერვერის პანელის backup ბაზას?

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

აღდგება თუ არა უფრო ახალი ვერსიის dump ძველ სერვერში?

ხშირად არა. dump-ები წინ თავსებადია და არა უკან: აღადგინე იმავე მთავარ ვერსიაში ან უფრო ახალში და ყოველთვის გამოიყენე ორი ბოლოდან უფრო ახალის ინსტრუმენტები. ვერსიის განახლებები დაგეგმე როგორც dump, დაყენება, აღდგენა, შემოწმება და არა როგორც ვარაუდი, რომ ფაილი ნებისმიერგან ჩაიტვირთება.

როგორ აღვადგინო ერთი ცხრილი ან კოლექცია?

PostgreSQL-ისთვის pg_restore -t tablename custom-ფორმატის dump-იდან, შინაარსის pg_restore -l-ით შემოწმების შემდეგ. MongoDB-სთვის mongorestore --nsInclude='db.collection'. ორივე შემთხვევაში ჯერ scratch ბაზაში აღადგინე და რიგები შემდეგ შეგნებულად გადაიტანე, რადგან მიზნობრივი აღდგენა არ იცნობს შეზღუდვებსა და მითითებებს, რომლებიც სხვაგან ამ ცხრილზე მიუთითებს.

რაც შეეხება როლებსა და პაროლებს?

pg_dump მათ არ შეიცავს; pg_dumpall --globals-only შეიცავს და ის იმავე backup ამოცანაში უნდა იყოს. MongoDB-სთვის მომხმარებლები admin ბაზაში ცხოვრობს და --restoreDbUsersAndRoles-ით ბრუნდება. აღდგენა, რომელიც მათ ივიწყებს, იძლევა მუშა ბაზას, რომელშიც შენი აპლიკაცია ვერ შედის. ბაზის უსაფრთხოების ჩამონათვალი ფარავს, ვის რომელი უნდა ჰქონდეს თავიდანვე.