VPS-ის სარეზერვო ასლი და აღდგენა: გამოსცადეთ პროცესი
სარეზერვო ასლი გამოსადეგია მაშინ, როცა VPS-ის გარედან მისი მიღება და საჭირო ფაილების აღდგენა შეგიძლიათ. ეს სავარჯიშო ქმნის სტატიკური გვერდისა და ერთი Nginx configuration-ის არქივს, გადააქვს სხვა კომპიუტერზე და ამოწმებს აღდგენილ მონაცემებს მოქმედი საიტის შეცვლის გარეშე.
VPSuntu · განახლებულია · წაკითხვა დაახლოებით 5 წუთში
გზამკვლევის შინაარსი
განსაზღვრეთ მცირე აღდგენის სავარჯიშო
გამოიყენეთ Bash, GNU tar, sha256sum და OpenSSH Ubuntu-ზე ან Linux/WSL კლიენტზე. სერვერისა და კლიენტის ბრძანებები ორ სხვადასხვა კომპიუტერზე, თითო ღია ტერმინალში შეასრულეთ, რათა ცვლადები შენარჩუნდეს. ნებისმიერი ბრძანების შეცდომის შემდეგ შეჩერდით.
მაგალითი home directory-ში ორ დროებით ფაილს იყენებს. Nginx, firewall და მოქმედი კონტენტი არ იცვლება; არქივის ამოღება root-ით არ სრულდება. ჯერ სატესტო ფაილებით დაიწყეთ. არჩევითი ნაბიჯი მხოლოდ სტატიკური HTTPS-საიტის ინსტრუქციის ორ ფაილს იყენებს.
დიდი საიტისთვის assets, redirects, included configuration, DNS და dependencies ცალკე აღრიცხეთ. ორი ფაილის მაგალითი სრული VM-ის ან აპლიკაციის backup არ არის.
მოამზადეთ ორი ფაილი საიტის შეუცვლელად
სერვერზე შექმენით private practice directory. ქვემოთ მოცემული configuration არქივისთვის განკუთვნილი ფაილია და გასააქტიურებელი service configuration არ არის.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="en"><title>Restore drill</title><h1>Recovered static page</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Practice directory: %s\n' "$backup_lab"არჩევითად შეგიძლიათ სატესტო ასლები ინსტრუქციის რეალური გვერდისა და server block-ის ასლებით ჩაანაცვლოთ. ორივე წყარო თქვენს მომხმარებელს უნდა ეკითხებოდეს. ჯერ შეამოწმეთ საიდუმლო მონაცემები და შეგროვებისას შეაჩერეთ deployment, რათა ფაილები ერთ release-ს ეკუთვნოდეს. სატესტო ვარიანტისთვის ეს ბლოკი გამოტოვეთ.
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"ბრძანებები მოქმედ წყაროებს მხოლოდ კითხულობს. ისინი certificate private keys-ს ან მთლიან system directories-ს არ აკოპირებს. საჭირო დამატებითი ფაილები შეგნებულად დაამატეთ inventory-სა და checksum manifest-ში.
შექმენით არქივი და საკონტროლო ჯამები
სერვერზე ჩაწერეთ ფაილების checksums, შექმენით relative paths-ის არქივი და შემდეგ არქივის checksum. ამ ეტაპზე საწყისი ფაილები უცვლელი დატოვეთ.
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Server export directory: %s\n' "$backup_lab/export"სიაში უნდა ჩანდეს site/, nginx/, ორი შერჩეული ფაილი და SHA256SUMS. არქივის checksum გადატანისას შეცვლილ არქივს გამოავლენს, შიდა manifest კი ამოღებულ ფაილებს ამოწმებს. თუ ვინმეს მონაცემებისა და მოსალოდნელი checksum-ის ერთდროულად შეცვლა შეუძლია, ეს შემოწმება ასლის ნამდვილობას ვერ ადასტურებს.
გადაიტანეთ ასლი სხვა კომპიუტერზე
კლიენტზე remote_backup-ში ჩაწერეთ სერვერის მიერ ზუსტად გამოტანილი export directory. მისამართი, მომხმარებელი და key filename შეცვალეთ მოქმედი SSH პარამეტრებით. 203.0.113.10 დოკუმენტაციის მისამართია; REPLACE ჩანაცვლების ნიშანია და არა mktemp-ის რეალური სუფიქსი.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"ახალი host key მიღებამდე გადაამოწმეთ სანდო არხით. თუ SCP SSH-ის გამო ვერ მუშაობს, გამოიყენეთ SSH-ის დიაგნოსტიკა. გადატანის გასამარტივებლად host-key checking არ გამორთოთ.
SCP გადაცემას SSH-ით იცავს. tar.gz შეკუმშულია, მაგრამ თავისთავად დაშიფრული არ არის. დაიცავით მიმღები ანგარიში და საცავი; საჭირო მონაცემებისთვის გამოიყენეთ საცავში დაშიფვრაც. იმავე VPS-ზე მეორე საქაღალდე დამოუკიდებელი ასლი არ არის.
შეამოწმეთ და აღადგინეთ ახალ ცარიელ საქაღალდეში
კლიენტზე ამოღებამდე გადაამოწმეთ არქივი. გააგრძელეთ მხოლოდ sha256sum-ის OK შედეგით. შეცდომა გამოიკვლიეთ ან თავიდან გადაიტანეთ ფაილი; მოსალოდნელ checksum-ს შეცდომის დასამალად ნუ გადააწერთ.
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"სანდო არქივი ახლად შექმნილ საქაღალდეში ამოიღეთ. keep-old-files არსებულ ფაილს არ გადაწერს; no-same-owner არქივის მფლობელს არ აღადგენს. დანიშნულება /-ით არ შეცვალოთ და sudo-თი არ ამოიღოთ.
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"მოსალოდნელია OK როგორც site/index.html-ისთვის, ისე nginx/first-site.conf-ისთვის, და აღდგენილი გვერდის სათაური. ეს ფაილების მონაცემებს ამოწმებს, მაგრამ არა production ownership-ს, ACL-ს, სერვისის ხელმისაწვდომობასა და საიტის ყველა დამოკიდებულებას.
ფაილის აღდგენა სერვისის აღდგენისგან გამოყავით
აღდგენილი configuration ჯერ მხოლოდ არააქტიური ტექსტური ფაილია. ცალკე replacement server-ზე შეამოწმეთ paths, includes, modules, permissions და certificates. იქ გადაამოწმეთ სრული Nginx configuration reload-მდე, შემდეგ HTTP/HTTPS გარედან გახსენით. უცვლელ მოქმედ სერვერზე syntax check ამ აღდგენილ ასლს არ ამოწმებს.
არქივში TLS private keys განზრახ არ შედის. დაგეგმეთ სერტიფიკატის ხელახალი გაცემა ან ცალკე დაცული certificate backup. მოქმედი database files ამ tar მაგალითით არ დააკოპიროთ: გამოიყენეთ ბაზის მხარდაჭერილი თანმიმდევრული backup/restore მეთოდი.
Provider snapshot შეიძლება VM-ის აღდგენაში დაგეხმაროთ, მაგრამ შეამოწმეთ retention, მარცხის საერთო რისკი და restore პროცედურა. Snapshot-ის არსებობა replacement host-ზე გატანილი საიტის ფაილების აღდგენას არ ადასტურებს.
ჩაწერეთ აღდგენის მიზანი და შედეგი
RPO დროში გამოხატული დასაშვები მონაცემების დანაკარგია; RTO — სერვისის აღდგენის სამიზნე დრო. მცირე სტატიკური საინფორმაციო საიტისთვის მაგალითად შეიძლება აირჩიოთ 24-საათიანი RPO და 60-წუთიანი RTO. ეს ბიზნესმიზნის მაგალითებია და არა ამ სავარჯიშოში გაზომილი შედეგები. ყოველდღიური ასლი დაგეგმილ სიხშირეს მხოლოდ წარმატებული და აღდგენადი კოპირებისას აკმაყოფილებს.
პატარა ეკრანზე ყველა სვეტის სანახავად ცხრილი ჰორიზონტალურად გადაახვიეთ.
| ჩანაწერი | რას ადასტურებს |
|---|---|
| Backup-ის დრო და release ID | რომელი ვერსიის აღდგენა შეგიძლიათ |
| დამოუკიდებელი დანიშნულება და retention | სად და რამდენ ხანს ინახება ასლი |
| არქივისა და ფაილების checksum შედეგები | აღდგა თუ არა შერჩეული მონაცემები |
| აღდგენის დაწყებისა და დასრულების დრო | კონკრეტულ ნაბიჯებზე დახარჯული დრო |
| გამოტოვებული ფაილები, permissions ან dependencies | რა რჩება სერვისის დაბრუნებამდე |
| გარე HTTPS შემოწმება replacement server-ზე | რეალურად დაბრუნდა თუ არა საიტი |
სანამ RTO-ს მიღწევადად ჩათვლით, გაზომეთ სრული პროცესი: წვდომა, provisioning, configuration, certificates და საჭიროებისას DNS. სწრაფი ლოკალური ამოღება შეფერხებისგან აღდგენის benchmark არ არის. შეინახეთ რამდენიმე გამოსადეგი აღდგენის წერტილი და აკონტროლეთ ჩავარდნილი backup jobs. საცავი და აღდგენის მხარდაჭერა შეადარეთ ჰოსტინგის კრიტერიუმებით.
ხშირი კითხვები
ტესტისთვის საწყისი საიტი უნდა წავშალო?
არა. ცარიელ ცალკე საქაღალდეში აღდგენა და manifest-ის შემოწმება ასლს შეფერხების შექმნის გარეშე ამოწმებს. სრული სერვისი ცალკე replacement გარემოში გამოსცადეთ.
წარმატებული checksum ნიშნავს, რომ მთელი საიტი დაკოპირებულია?
ის ადასტურებს მხოლოდ manifest-ში ჩამოთვლილ ფაილებს. გამოტოვებულ asset-ს, database-ს, secret-ს ან DNS setting-ს ვერ აღმოაჩენს. იქონიეთ inventory და აღდგენის შემდეგ საიტის რეალური ფუნქციებიც გამოსცადეთ.