სარეზერვო ასლები და კატასტროფიდან აღდგენა

# Daily logical dump
pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump

aihummer backup [dir]      # write a backup into [dir]
aihummer restore <file>    # restore from a backup file

AiHummer-ის მდგომარეობა მცირე და კარგად განსაზღვრულია, რაც სარეზერვო ასლების აღებას პირდაპირს ხდის — სანამ გახსოვთ, რომ **მთავარი გასაღები ბაზაში არ არის** და დაცული უნდა იყოს ცალკე. ეს გვერდი ფარავს რა უნდა დაარეზერვოთ, როგორ და როგორ აღადგინოთ. ## რა უნდა დაარეზერვოთ არსებობს სამი დამოუკიდებელი დასაცავი რამ: | რა | სად | რატომ | |---|---|---| | **ბაზა** | PostgreSQL | ჭეშმარიტების წყარო — აგენტები, საუბრები, მეხსიერება, პარამეტრები, დაშიფრული საიდუმლოები | | **Blob-ები** | `AIHUMMER_BLOB_DIR` | მედია და ფაილების დანართები, რომელზეც ბაზა მიუთითებს | | **მთავარი გასაღები** | `AIHUMMER_MASTER_KEY` | შიფრავს vault-ს; **არასოდეს ინახება ბაზაში** | > [!DANGER] > დაარეზერვეთ `AIHUMMER_MASTER_KEY` **ცალკე** და შეინახეთ ის ბაზის dump-ისგან > განსხვავებულ ადგილას. vault დაშიფრულია envelope-შიფრვით ამ გასაღების ქვეშ — > **დაკარგეთ მთავარი გასაღები და დაშიფრული საიდუმლოები აღუდგენელია**, თუნდაც ბაზის > სრულყოფილი სარეზერვო ასლით. ## PostgreSQL არის ჭეშმარიტების წყარო მოეპყარით ბაზას როგორც ავტორიტეტულს. რეკომენდებული საფუძველი არის **ყოველდღიური `pg_dump`** პლუს **WAL არქივირება point-in-time აღდგენისთვის (PITR)**, ასე რომ შეგიძლიათ წინ გადახვიდეთ dump-ებს შორის ნებისმიერ მომენტამდე. ```bash # Daily logical dump pg_dump "$AIHUMMER_DATABASE_URL" --format=custom --file=aihummer-$(date +%F).dump ``` დააწყვილეთ dump-ები უწყვეტ WAL არქივირებასთან (PITR) წერტილებს შორის წვრილმარცვლოვანი აღდგენისთვის. ## Blob-ების რეზერვირება მედია და ფაილების დანართები ცხოვრობს `AIHUMMER_BLOB_DIR`-ის ქვეშ. დაარეზერვეთ ეს დირექტორია ბაზის გვერდით, რათა აღდგენილ საუბრებს ისევ შეეძლოთ თავიანთი დანართების გადაჭრა. თუ `AIHUMMER_BLOB_DIR` არ არის კონფიგურირებული, მედია/ფაილის სერვისი არ არის აქტიური და დამატებით კოპირებისთვის არაფერია. ## aihummer backup და restore ბრძანებები CLI აერთიანებს რუტინას ორ ბრძანებაში: ```bash aihummer backup [dir] # write a backup into [dir] aihummer restore <file> # restore from a backup file ``` გამოიყენეთ ეს ჩვეულებრივი ოპერაციული სარეზერვო ასლებისა და აღდგენებისთვის. დაკავშირებული ბრძანებებისთვის იხილეთ [CLI ცნობარი](/ka/v1.0/reference/cli). > [!WARNING] > მხოლოდ ბაზის აღდგენა არ არის სრული აღდგენა. აღადგინეთ blob დირექტორიაც და > დარწმუნდით, რომ **იგივე** `AIHUMMER_MASTER_KEY` არსებობს სამიზნე ჰოსტზე — წინააღმდეგ > შემთხვევაში vault-ის გაშიფვრა შეუძლებელია. ## კატასტროფიდან აღდგენა ჰოსტის სრული დაკარგვის სცენარისთვის მიჰყევით **კატასტროფიდან აღდგენის runbook-ს** (`docs/runbooks/disaster-recovery.md`). აღდგენის თანმიმდევრობა არის: 1. მოამზადეთ ჰოსტი და დააინსტალირეთ AiHummer-ის იგივე ვერსია. 2. აღადგინეთ **მთავარი გასაღები** `AIHUMMER_MASTER_KEY`-ში. 3. აღადგინეთ **ბაზა** (უახლესი dump, შემდეგ წინ გადასვლა WAL/PITR-ით, თუ გამოყენებულია). 4. აღადგინეთ **blob დირექტორია** `AIHUMMER_BLOB_DIR`-ზე. 5. ააწიეთ სერვისები (`aihummer up`) და გადაამოწმეთ `/readyz`-ით და `deploy/host/smoke.sh`-ით. > [!TIP] > ასევე შეინახეთ `AIHUMMER_MEDIA_TOKEN_SECRET` თქვენს მთავარ გასაღებთან ერთად. ის > ინარჩუნებს ხელმოწერილ მედია-ჩამოტვირთვის URL-ებს ვალიდურად რესტარტებსა და ხელახალ > აგებებს შორის. ## სად შემდეგ - ზონდები და smoke ტესტი, რომელიც გამოიყენება აღდგენის გადასამოწმებლად: [systemd და ჯანმრთელობის შემოწმებები](/ka/v1.0/operations/systemd-health). - ვერსირება და მიგრაციები განახლების დროს: [განახლების პოლიტიკა](/ka/v1.0/operations/upgrade-policy). </content> </invoke>