ბექაპი, რომელიც არავის აღუდგენია, ბექაპად არ ითვლება: კვირის სამი ინსტრუმენტი

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

რა გამოვიდა

PostgreSQL News-მა 22 ოქტომბერს BackupDrill-ის ანონსი გამოაქვეყნა. ინსტრუმენტი Supabase-ში მდგომი ბაზიდან pg_dump-ს იღებს, არქივს საკონტროლო ჯამით თქვენს S3-თავსებად bucket-ში დებს, შემდეგ კი ბრძანებით backupdrill drill ბოლო ასლს ერთჯერად PostgreSQL კონტეინერში აღადგენს და ამოწმებს: არქივი მთელია, pg_restore დასრულდა, ინდექსები და შეზღუდვები შექმნილია, ყველა ცხრილი ადგილზეა, ხოლო ისინი, სადაც მონაცემები იყო, ცარიელი არ არის. აღდგენის დრო იწერება. CLI MIT ლიცენზიითაა, არის ფასიანი სერვისი განრიგით და უფასო გეგმით. ჯერჯერობით მხოლოდ Supabase-სთვის.

იმავე დღეს იქვე გამოვიდა SafeGrd PostgreSQL 13-ისა და უფრო ახლებისთვის. დემონი ბაზის გვერდით დგას, მხოლოდ წაკითხვის როლით უერთდება, ასლს age გასაღებით ჯერ კიდევ თქვენს ჰოსტზე შიფრავს და Object Lock-იან S3 bucket-ში წერს. შემოწმებას Fire Drill-ს უწოდებენ: ასლს ან მეხსიერებაში ათამაშებენ და ცხრილების, სტრიქონებისა და სვეტების რაოდენობას გადაღებისას ჩაწერილს ადარებენ, ან sandbox-ში აღადგენენ, და იქ საკუთარი SQL-შემოწმებების დამატება შეიძლება. ყოველი შემოწმება ხელმოწერილ ჩანაწერს ტოვებს, და ჩანაწერები ჯაჭვშია გადაბმული. უფასო გეგმა ერთ ბაზაზე: ასლი დღეში ერთხელ, შემოწმება მეხსიერებაში კვირაში ერთხელ; ფასიანი $15-დან თვეში.

ცოტა ადრე, 18 ოქტომბერს, გამოვიდა pgBackRest 2.60.0. მთავარი ცვლილება ქცევაში: აღდგენა ახლა შეცდომით ჩერდება, თუ აღდგენილ ფაილში გვერდის საკონტროლო ჯამი არასწორია, ხოლო ბრძანება expire ძველი ასლების წაშლაზე უარს იტყვის, თუ დარჩენილთაგან ყველაზე ძველი ასეთ შეცდომებს შეიცავს. ეს ოფციით checksum-page-error=n ითიშება.

Camunda-მ 19 ოქტომბერს 8.10 Self-Managed ვერსიაში კლასტერის აღდგენა აღწერა. ადრე ბროკერებს აჩერებდნენ, კატალოგებს ხელით ასუფთავებდნენ და ცალკე აპლიკაციას უშვებდნენ; ახლა ეს REST API-ის რამდენიმე გამოძახებაა: კლასტერის RECOVERING რეჟიმში გადაყვანა, საცავის აღდგენა, POST /v2/restore-ის გამოძახება ასლის ID-ით. მომეწონა მათი ფორმულირება: აღდგენის გეგმა, რომელიც არავის შეუსრულებია, გეგმა კი არა, შეფასებაა. ისინი გვთავაზობენ, კვარტალში ერთხელ ღამის ასლი იმ კლასტერში აღდგეს, რომელზეც არავინაა დამოკიდებული, და დრო ჩაინიშნოს.

რატომ სჭირდება ეს ბიზნესს

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

გარანტიას მხოლოდ ის აღდგენა იძლევა, რომელიც ვიღაცამ ახლახან გააკეთა, ცალკე მანქანაზე, და რის შემდეგაც მთავარ ცხრილებში სტრიქონები დათვალა. კვირის ოთხივე სიახლე იმაზეა, როგორ ჩაისვას ეს ნაბიჯი განრიგში.

როგორ მაქვს ეს მოწყობილი

თითქმის ყველა ჩემს პროექტში MariaDB დგას და არა PostgreSQL, ამიტომ BackupDrill და SafeGrd პირდაპირ არ მერგება და ჩემთან არ შემიმოწმებია. პრინციპი იგივეა, ინსტრუმენტები ჩემი.

აშშ-ში PDR-კომპანიასთან 2021 წლიდან ვმუშაობ. 2022-ში მისთვის Google Cloud-ში Debian-ზე სერვერი დავაყენე და მას შემდეგ თავად ვუვლი: სერვერს, VPN-ს, ქსელურ აპარატურასა და ტელეფონიას. სისტემას დაცვისა და სარეზერვო ასლების რამდენიმე კონტური აქვს. 2022 წლიდან აღდგენასთან დაკავშირებული სერიოზული ჩავარდნა არ ყოფილა. ამას იღბლად არ ვთვლი: ასლები არის, და ვიცი, რომ მათგან სისტემა აღდგება.

ჰიდროპონიკურ ფერმაზე, სადაც 2023 წლიდან სერვერსა და ქსელზე ვაგებ პასუხს, MariaDB ბაზა იმავე Debian ვირტუალურ მანქანაზე დგას, რომელზეც სერვერი, და იქ ორ ობიექტზე მდგომი 25 კონტროლერიდან მონაცემები მოდის. ბაზის დაკარგვა იქ მაჩვენებლების ისტორიის დაკარგვას ნიშნავს, რომლითაც სხვა გუნდი ავტომატიზაციას აგებს.

სტუდიის სერვერზე, სადაც შიდა სერვისი „ყავა ერთად“ მუშაობს, SQLite ბაზა Docker volume-ში დევს. სერვერი საერთოა, 2 GB მეხსიერებით, ამიტომ ასლის შემოწმება იქ ასე არის მოსახერხებელი: კონტეინერი გვერდით ეშვება, ასლს კითხულობს და ითიშება. აღდგენის დროის ციფრებს არ ვაქვეყნებ.

რას გავაკეთებდი

ჰკითხეთ კონტრაქტორს, სად ინახება ასლები და რამდენი ხანია ერთ-ერთი აღადგინეს. პასუხი „ავტომატურად კეთდება“ არ ითვლება.

დანიშნეთ დღე. თვეში ერთხელ ასლი ცალკე კონტეინერში აღდგება, და ვიღაც სამ-ხუთ მთავარ ცხრილში სტრიქონების რაოდენობას ადარებს: განაცხადები, კლიენტები, დოკუმენტები. როგორც SafeGrd-ში, საკუთარი მოთხოვნების დამატება შეიძლება, მაგალითად „რამდენი გარიგებაა კლიენტის გარეშე“.

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

ასლები იქ არ შეინახოთ, სადაც ბაზაა. ცალკე bucket ან სხვა სერვერი, და ისე, რომ მათი წაშლა იმავე გასაღებით არ შეიძლებოდეს, რომლითაც იწერება. SafeGrd-ის Object Lock სწორედ ამისთვისაა.

ჩაიწერეთ შედეგი: თარიღი, ვინ შეამოწმა, რამდენი დრო დასჭირდა, რა არ დაემთხვა. ერთ წელიწადში ამ ჩანაწერებით ჩანს, ბაზა აღდგენის გეგმაზე სწრაფად იზრდება თუ არა.

იმაზე, რატომ სჭირდება სისტემას მონაცემების საერთო ცენტრი და როგორ უნდა გადაიტანოს მან ჩავარდნები, სტატიაში სერვერი: მონაცემები, წვდომა და პროცესის შესრულება დავწერე, ხოლო ექსპლუატაციის მიდგომა გვერდზე ინფრასტრუქტურა, რომლის გამოშვება და აღდგენა შეიძლება არის შეკრებილი. ქეისები: PDR-კომპანიის ტექნიკური პარტნიორი და ჰიდროპონიკური ფერმის სერვერი და ქსელი. იმავე თემაზე: როგორ ვამოწმებ სერვერებს, როცა მსოფლიო კრიტიკულ ხვრელს ამაგრებს და რას ვანდობდი AI-მორიგეს ერთ სერვერზე. ადრე ვწერდი, რომ ასლი დაცვა შემოწმებული აღდგენის შემდეგ ხდება და რომ დეპლოების შენახვის ვადა აღდგენის გეგმას უნდა ემთხვეოდეს. თუ არ იცით, აღდგება თუ არა თქვენი ბაზა, აღწერეთ, სად დგას: ამოცანის განხილვა.