VPS-ի պահուստավորում և վերականգնում․ փորձարկեք պատճենը
Պահուստային պատճենն օգտակար է, երբ այն կարող եք ստանալ VPS-ից դուրս և վերականգնել սպասվող ֆայլերը։ Այս փորձը արխիվացնում է ստատիկ էջն ու մեկ Nginx configuration, փոխանցում այլ համակարգչի և ստուգում վերականգնված տվյալները՝ գործող կայքին չդիպչելով։
VPSuntu · Թարմացվել է · Ընթերցում՝ մոտ 5 րոպե
Ուղեցույցի բովանդակությունը
Սահմանեք փոքր վերականգնման փորձը
Օգտագործեք Bash, GNU tar, sha256sum և OpenSSH՝ Ubuntu կամ Linux/WSL կլիենտում։ Սերվերի հրամանները պահեք մեկ սերվերային տերմինալում, կլիենտինը՝ առանձին համակարգչի մեկ տերմինալում։ Սեսիաները բաց թողեք, որպեսզի փոփոխականները պահպանվեն։ Ցանկացած հրամանի սխալից հետո կանգ առեք։
Օրինակը home directory-ում երկու ժամանակավոր ֆայլ է ստեղծում։ Այն չի փոխում Nginx-ը, firewall-ը կամ գործող բովանդակությունը, իսկ extraction-ը root-ով չի կատարվում։ Սկսեք փորձնական ֆայլերից։ Ընտրովի փոխարինումն օգտագործում է միայն ստատիկ HTTPS տեղակայման երկու ֆայլերը։
Մեծ կայքի assets-ը, redirects-ը, included configuration-ը, DNS-ը և կախվածություններն առանձին հաշվառեք։ Երկու ֆայլի օրինակը ամբողջ մեքենայի կամ հավելվածի backup չէ։
Պատրաստեք երկու ֆայլ՝ կայքը չփոխելով
Սերվերում ստեղծեք private practice directory։ Ստորև 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-ի պատճեններով։ Երկու աղբյուրներն էլ պետք է կարդացվեն ձեր հաշվից։ Նախ configuration-ում ստուգեք secrets-ը և հավաքման ժամանակ դադարեցրեք deployments-ը, որպեսզի ֆայլերը նույն 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 կամ ամբողջ համակարգային թղթապանակներ չեն պատճենվում։ Իրական կայքի լրացուցիչ ֆայլերը գիտակցաբար ավելացրեք և՛ 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-ը ստուգում է extracted ֆայլերը։ Դրանք backup-ի իսկությունը չեն հաստատում, եթե ինչ-որ մեկը կարող է և՛ տվյալները, և՛ սպասվող checksum-ը փոխարինել։
Պատճենը փոխանցեք առանձին համակարգչի
Կլիենտում remote_backup-ին տվեք սերվերի տպած ճշգրիտ export directory-ն։ Օրինակի հասցեն, հաշիվն ու key filename-ը փոխեք ձեր աշխատող SSH տվյալներով։ 203.0.113.10-ը փաստաթղթային հասցե է, REPLACE-ը՝ փոխարինման նշիչ, ոչ mktemp-ի ստեղծած suffix։
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-ն ընդունելուց առաջ fingerprint-ը ստուգեք վստահելի ուղով։ Եթե SSH-ն խանգարում է փոխանցմանը, օգտագործեք SSH-ի ախտորոշումը։ Հաջող փոխանցման համար host-key checking մի անջատեք։
SCP-ն փոխանցումը պաշտպանում է SSH-ով։ tar.gz ֆայլը սեղմված է, ոչ ինքնաբերաբար գաղտնագրված․ պաշտպանեք նպատակային հաշիվն ու storage-ը և անհրաժեշտության դեպքում կիրառեք encryption at rest։ Նույն VPS-ի երկրորդ թղթապանակը off-server պատճեն չէ։
Ստուգեք և վերականգնեք նոր դատարկ թղթապանակում
Կլիենտում նախ ստուգեք արխիվը։ Շարունակեք միայն 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-ը չի վերականգնում արխիվի ownership-ը։ Նպատակային ուղին երբեք / մի դարձրեք և sudo-ով extraction մի կատարեք։
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-ը։ Այնտեղ validate արեք հավաքված Nginx configuration-ը մինչև reload-ը, հետո դրսից ստուգեք HTTP/HTTPS-ը։ Չփոխված գործող սերվերի syntax check-ը այս պատճենը չի ստուգում։
Այս արխիվը դիտավորյալ չի ներառում TLS private keys։ Պլանավորեք certificate reissuance կամ առանձին պաշտպանված backup։ Գործող database files-ը այս tar օրինակով մի պատճենեք․ կիրառեք բազայի աջակցվող consistent backup/restore ընթացակարգը։
Provider snapshots-ը կարող է օգնել մեքենայի վերականգնմանը, բայց ստուգեք retention-ը, failure domain-ը և restore ընթացքը։ Snapshot-ի գոյությունը չի ապացուցում արտահանված կայքի վերականգնումը այլ host-ում։
Գրանցեք վերականգնման նպատակն ու արդյունքը
RPO-ն ժամանակով արտահայտված ընդունելի տվյալների կորուստն է, RTO-ն՝ ծառայության վերադարձի նպատակային ժամանակը։ Փոքր ստատիկ տեղեկատվական կայքի համար օրինակ կարող եք ընտրել 24-ժամյա RPO և 60-րոպեանոց RTO։ Սրանք բիզնես նպատակների օրինակներ են, ոչ այս փորձի չափումներ։ Ամենօրյա backup-ը պլանին համապատասխանում է միայն, երբ պատճենները հաջողվում են և մնում վերականգնելի։
Փոքր էկրանին բոլոր սյունակները տեսնելու համար աղյուսակը ոլորեք հորիզոնական։
| Գրառում | Ինչ է ցույց տալիս |
|---|---|
| Backup-ի ժամը և release ID-ն | Որ տարբերակը կարող եք վերականգնել |
| Անկախ նպատակային պահեստ և retention | Որտեղ և որքան է պահպանվում պատճենը |
| Արխիվի ու ֆայլերի checksum արդյունքներ | Վերականգնվե՞լ են ընտրված տվյալները |
| Restore-ի սկիզբն ու ավարտը | Սահմանված քայլերի տևողությունը |
| Բացակայող ֆայլեր, permissions կամ dependencies | Ինչ է մնում մինչև ծառայության վերադարձը |
| Արտաքին HTTPS ստուգում նոր սերվերում | Վերադարձե՞լ է կայքը իրականում |
RTO-ն իրատեսական համարելուց առաջ չափեք ամբողջ replacement-ը՝ մուտք, provisioning, configuration, certificates և անհրաժեշտ DNS։ Արագ տեղային extraction-ը outage recovery benchmark չէ։ Պահեք մի քանի հարմար restore point և հետևեք backup jobs-ի ձախողումներին։ Պահեստն ու restore աջակցությունը համեմատեք հոսթինգի պահանջներով։
Հաճախ տրվող հարցեր
Թեստի համար ջնջե՞մ սկզբնական կայքը։
Պետք չէ։ Առանձին դատարկ թղթապանակում restore-ը և manifest-ի ստուգումը պատճենը փորձարկում են առանց outage-ի։ Ամբողջ ծառայությունը փորձարկեք առանձին replacement միջավայրում։
Հաջող checksum-ը նշանակո՞ւմ է, որ ամբողջ կայքը պահուստավորված է։
Այն հաստատում է միայն manifest-ի ֆայլերը։ Չի հայտնաբերում բաց թողնված asset, database, secret կամ DNS setting։ Պահեք inventory և ծառայությունը վերականգնելուց հետո փորձարկեք իրական գործառույթները։