რა მოხდება, თუ restic-ის პაროლს დავკარგავ?

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

სად უნდა იყოს საცავი?

ნებისმიერ ადგილას, გარდა თავად სერვერისა: S3-თავსებად ობიექტურ საცავში, SFTP-ით მიერთებულ სხვა VPS-ზე ან სახლის მანქანაზე. იმავე დისკზე არსებული ასლი ამ დისკთან ერთად კვდება.

როგორ ავიღო მონაცემთა ბაზის ასლი restic-ით?

ჯერ გააკეთეთ dump და შემდეგ dump-ის ასლი აიღეთ — PostgreSQL-ისთვის 'pg_dump -Fc', MySQL-ისთვის 'mysqldump --single-transaction'. გაშვებული მონაცემთა ბაზის ფაილების კოპირებამ შეიძლება ისეთი ასლი მოგცეთ, რომელიც არ ჩაირთვება.

რამდენ ადგილს იკავებს სარეზერვო ასლები?

იმაზე ნაკლებს, ვიდრე ფიქრობთ. restic ფაილებს ნაწილებად ყოფს და თითოეულ ნაწილს ერთხელ ინახავს, ამიტომ თითქმის უცვლელი სერვერის ყოველდღიური snapshot-ები მხოლოდ შეცვლილ მონაცემებს ამატებს.

ისევ მჭირდება Managed Backups?

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

როგორ შევქმნათ VPS-ის სარეზერვო ასლი restic-ით (დაშიფრული, სერვერის გარეთ)

დაშიფრული, დედუბლიცირებული VPS-ის სარეზერვო ასლები restic-ით: საცავი S3-თავსებად საცავში ან სხვა სერვერზე, systemd-ტაიმერი, შენახვის წესები და აღდგენის ტესტი.

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

აი კონფიგურაცია, რომელსაც ჩვენ ნამდვილად ვენდობოდით, Ubuntu-ზე ან Debian-ზე.

1. დააინსტალირეთ restic

apt update && apt install -y restic
restic self-update

დისტრიბუტივის პაკეტები ჩამორჩება; self-update მიმდინარე ვერსიას ჩამოტვირთავს.

2. აირჩიეთ ადგილი საცავისთვის

საცავი არ უნდა იყოს იმ სერვერზე, რომელსაც იცავთ. ორი გავრცელებული არჩევანი:

სხვა სერვერი SFTP-ით: sftp:backup@203.0.113.20:/srv/restic/web1
S3-თავსებადი ობიექტური საცავი: s3:https://s3.example.com/my-bucket/web1

3. შეინახეთ მონაცემები წვდომისთვის

ყველაფერი ერთ ფაილში შეინახეთ, რომელსაც მხოლოდ root კითხულობს, რომ ტაიმერმა და თქვენმა shell-მა ერთი და იგივე პარამეტრები გამოიყენონ:

cat > /root/.restic-env <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example.com/my-bucket/web1"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"
export AWS_ACCESS_KEY_ID="your-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret"
EOF
openssl rand -base64 32 > /root/.restic-pass
chmod 600 /root/.restic-env /root/.restic-pass

ახლა დააკოპირეთ /root/.restic-pass-ის შიგთავსი თქვენს პაროლების მენეჯერში. მის გარეშე ასლების გაშიფვრა შეუძლებელია — არც თქვენ და არც სხვა ვინმეს.

4. მოამზადეთ საცავი და აიღეთ პირველი ასლი

source /root/.restic-env
restic init
restic backup /etc /home /root /srv /var/www \
  --exclude-caches --exclude '/root/.cache'
restic snapshots

გზები მოარგეთ იმას, სადაც თქვენი მონაცემები რეალურად არის. Docker-ის ვოლიუმები /var/lib/docker/volumes-შია; აპლიკაციების მონაცემები ხშირად /srv-ში ან /opt-ში.

5. მონაცემთა ბაზები: ჯერ dump, მერე ასლი

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

mkdir -p /var/backups/db
sudo -u postgres pg_dump -Fc mydb > /var/backups/db/mydb.dump

დაამატეთ /var/backups/db ასლის გზებში. dump-ების შესახებ მეტი ჩვენს PostgreSQL-ის სახელმძღვანელოშია.

6. დაგეგმეთ systemd-ით

აქ ტაიმერი cron-ზე უკეთესია: ის journal-ში წერს და თუ დანიშნულ დროს სერვერი გამორთული იყო, გაშვებას მოგვიანებით ანაზღაურებს.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=restic backup

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'source /root/.restic-env && restic backup /etc /home /root /srv /var/www /var/backups/db --exclude-caches && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune'

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Daily restic backup

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now restic-backup.timer
systemctl list-timers restic-backup.timer

forget --prune ინახავს 7 ყოველდღიურ, 4 ყოველკვირეულ და 6 ყოველთვიურ snapshot-ს, დანარჩენს კი შლის. თუ მონაცემთა ბაზის dump-ის ნაბიჯი გაქვთ, ჩასვით ის ExecStartPre= ხაზში.

7. ნამდვილად აღადგინეთ რამე

სწორედ ეს ნაბიჯი აქცევს „ასლები გვაქვს"-ს ფაქტად. ერთი საქაღალდე დროებით საქაღალდეში დააბრუნეთ და დაათვალიერეთ:

source /root/.restic-env
restic restore latest --target /tmp/restore-test --include /etc/nginx
ls -la /tmp/restore-test/etc/nginx
restic check

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

restic და Managed Backups

ისინი ერთმანეთს არ ეჯიბრებიან. Managed Backups ყოველდღე მთელი სერვერის აღდგენის წერტილს ქმნის, რომელსაც სამართავი პანელიდან აბრუნებთ — სწრაფი გამოსავალი წარუმატებელი განახლების შემდეგ. ისინი თვეში $2 ღირს და ნებისმიერ წლიურ გეგმაში უფასოდ შედის. restic კი ფაილების დონის ასლებს სერვერის გარეთ, თქვენი კონტროლის ქვეშ მყოფ საცავში გაძლევთ, რაც მნიშვნელოვანია, როცა პრობლემა გასულ სამშაბათს წაშლილი ფაილია, ან როცა ასლი ჩვენი ინფრასტრუქტურის სრულიად გარეთ გინდათ.

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