បម្រុងទុកនិងស្ដារ VPS ដោយមិនប៉ះគេហទំព័រកំពុងដំណើរការ
Backup មានប្រយោជន៍ពេលអ្នកយកវាចេញពី VPS ហើយស្ដារឯកសារដែលរំពឹងបាន។ លំហាត់នេះដាក់ static page និង Nginx config មួយក្នុង archive ចម្លងទៅកុំព្យូទ័រផ្សេង ហើយផ្ទៀងផ្ទាត់ទិន្នន័យដែលស្ដារដោយមិនប៉ះគេហទំព័រកំពុងដំណើរការ។
VPSuntu · កែថ្មី៖ · អានប្រហែល 5 នាទី
មាតិកាទំព័រ
កំណត់វិសាលភាពលំហាត់សង្គ្រោះ
ប្រើ Bash, GNU tar, sha256sum និង OpenSSH លើ Ubuntu ឬ Linux/WSL client ។ Server commands រត់ក្នុង server terminal មួយ; client commands ក្នុង terminal មួយលើកុំព្យូទ័រដាច់ដោយឡែក។ រក្សា terminal នីមួយៗឱ្យបើក ដើម្បីរក្សា variables ។ បើពាក្យបញ្ជាណាមានកំហុស សូមឈប់។
លំហាត់ប្រើឯកសារបណ្ដោះអាសន្នពីរនៅក្រោម home directory ។ វាមិនកែ Nginx, firewall ឬ live content ហើយមិន extract ជា root ។ ចាប់ផ្ដើមពី fixtures ខាងក្រោម; ជម្រើសផ្សេងប្រើតែឯកសារពីរពីមគ្គុទ្ទេសក៍ static HTTPS។
សម្រាប់ site ធំជាង ត្រូវរាយ assets, redirects, included config, DNS និង dependencies ផ្សេងទៀត។ គំរូពីរឯកសារមិនមែន machine ឬ application backup ពេញលេញ។
រៀបចំពីរឯកសារដោយមិនកែគេហទំព័រ
លើ server បង្កើត practice directory ឯកជន។ Configuration ខាងក្រោមជាឯកសារសម្រាប់ archive មិនមែន service config ដែលត្រូវ activate ។
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"ជម្រើស៖ បើចង់ backup page និង server block ពិតរបស់មគ្គុទ្ទេសក៍ ជំនួសតែច្បាប់ចម្លងបណ្ដោះអាសន្នតាមខាងក្រោម។ គណនីអ្នកត្រូវអាន source files ទាំងពីរបាន។ ពិនិត្យ secrets ក្នុង config ហើយផ្អាក deployments ពេលប្រមូលឯកសារ ដើម្បីឱ្យជាកំណែដូចគ្នា។ សម្រាប់ fixture exercise រំលង block នេះ។
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"ពាក្យបញ្ជាអាន live sources ដោយមិនកែវា។ វាមិនចម្លង certificate private keys ឬ system directories ទាំងមូល។ Site ពិតអាចត្រូវការឯកសារបន្ថែម; បន្ថែមដោយចេតនាទាំងក្នុង inventory និង checksum manifest ។
បង្កើត archive និង checksums ពីរកម្រិត
លើ server កត់ checksums របស់ឯកសារជ្រើសរើស បង្កើត archive ដោយប្រើ relative paths រួច checksum archive ។ កុំប្ដូរ payload ក្នុងជំហាននេះ។
(
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 ។ Archive checksum រកការប្ដូរពេលផ្ទេរ; manifest ខាងក្នុងពិនិត្យឯកសារក្រោយ extract ។ ទាំងពីរមិនផ្ទៀងផ្ទាត់ប្រភព backup បើនរណាម្នាក់អាចជំនួសទាំងទិន្នន័យនិង checksum ដែលរំពឹង។
ចម្លង backup ទៅកុំព្យូទ័រដាច់ដោយឡែក
លើ client កំណត់ remote_backup ទៅ export directory ពិតដែល server បង្ហាញ។ ប្ដូរ IP, account និង key filename ទៅ SSH details ដែលប្រើបាន។ 203.0.113.10 ជា documentation address; REPLACE ជា placeholder មិនមែន suffix ពិតពី 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/"ផ្ទៀងផ្ទាត់ SSH host fingerprint តាមផ្លូវទុកចិត្តមុនទទួល host ថ្មី។ បើ SCP បរាជ័យដោយសារ SSH ប្រើមគ្គុទ្ទេសក៍ដោះស្រាយ SSH។ កុំបិទ host-key checking ដើម្បីឱ្យ copy បាន។
SCP ការពារការផ្ទេរតាម SSH ។ ឯកសារ tar.gz ត្រូវបាន compress មិនបាន encrypt; ការពារ destination account និង storage ហើយប្រើ encryption at rest បើទិន្នន័យត្រូវការ។ ថតទីពីរលើ VPS ដដែលមិនមែន off-server copy ។
ផ្ទៀងផ្ទាត់ ហើយស្ដារចូលថតទទេថ្មី
លើ client ពិនិត្យ archive មុន extract ។ បន្តតែពេល sha256sum បង្ហាញ OK ។ បើបរាជ័យ ត្រូវស៊ើបឬផ្ទេរថ្មី; កុំសរសេរជាន់ expected checksum ដើម្បីលាក់កំហុស។
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Extract archive ដែលទុកចិត្តនេះទៅ directory បង្កើតថ្មី។ Keep-old-files មិនអនុញ្ញាតជំនួសឯកសារចាស់; no-same-owner មិនស្ដារ ownership ពី archive ។ កុំប្ដូរ destination ទៅ / ឬ extract ជាមួយ 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 ព្រមទាំងចំណងជើង page ដែលស្ដារ។ នេះផ្ទៀងផ្ទាត់ file contents មិនមែន production ownership, ACLs, service availability ឬ dependencies ទាំងអស់។
បែងចែកការស្ដារឯកសារ និងការស្ដារសេវា
Configuration ដែលស្ដារនៅតែជាអត្ថបទមិនសកម្ម។ មុនប្រើ ពិនិត្យ paths, includes, modules, permissions និង certificates លើ replacement server ដាច់ដោយឡែក។ Validate Nginx config ទាំងមូលនៅទីនោះមុន reload រួចពិនិត្យ HTTP/HTTPS ពីខាងក្រៅ។ Syntax check លើ live server មិនបានកែមិន validate ច្បាប់ចម្លងស្ដារនេះទេ។
Archive នេះមិនរាប់ TLS private keys ដោយចេតនា។ រៀបចំ certificate reissuance ឬ backup certificates ដែលការពារដាច់ដោយឡែក។ កុំ copy active database files តាម tar recipe នេះ; ប្រើ consistent backup/restore ដែល database គាំទ្រ។
Provider snapshots អាចជួយ machine recovery ប៉ុន្តែត្រូវពិនិត្យ retention, failure domain និង restore procedure ។ Snapshot មានស្រាប់មិនបញ្ជាក់ថា exported site files ស្ដារលើ host ថ្មីបានទេ។
កត់គោលដៅសង្គ្រោះ និងលទ្ធផល
RPO ជាកម្រិតបាត់ទិន្នន័យដែលទទួលបាន គិតជាពេលវេលា។ RTO ជាពេលគោលដៅស្ដារសេវា។ សម្រាប់ static information site តូច អាចកំណត់ RPO 24 ម៉ោង និង RTO 60 នាទី។ នេះជាគំរូគោលដៅអាជីវកម្ម មិនមែនលទ្ធផលបានវាស់ក្នុងលំហាត់។ Backup ប្រចាំថ្ងៃបំពេញគោលដៅតែពេល copy ជោគជ័យ និងនៅស្ដារបាន។
លើអេក្រង់តូច អូសតារាងទៅចំហៀងដើម្បីមើលគ្រប់ជួរឈរ។
| អ្វីត្រូវកត់ | អ្វីដែលបញ្ជាក់ |
|---|---|
| ពេល backup និង release ID | កំណែដែលអាចស្ដារ |
| Destination ឯករាជ្យនិង retention | កន្លែងច្បាប់ចម្លងរស់នៅ និងរយៈពេល |
| Archive/file checksum results | ទិន្នន័យជ្រើសរើសបានស្ដារត្រឹមត្រូវឬទេ |
| ពេលចាប់ផ្ដើមនិងបញ្ចប់ restore | ពេលចំណាយលើជំហានបានកំណត់ |
| Files, permissions ឬ dependencies ខ្វះ | ការងារនៅសល់មុនសេវាត្រឡប់ |
| External HTTPS លើ replacement | គេហទំព័រពិតជាត្រឡប់ឬទេ |
វាស់ replacement process ទាំងមូលមុនចាត់ទុក RTO ថាអាចសម្រេចបាន៖ access, provisioning, config, certificates និង DNS បើត្រូវការ។ Extract លឿនលើ local មិនមែន outage-recovery benchmark ។ រក្សា restore points សមស្របច្រើន និងពិនិត្យ backup jobs បរាជ័យ។ ប្រៀបធៀប retention និង restore support ក្នុងលក្ខខណ្ឌជ្រើស hosting។
សំណួរនិងចម្លើយ
ត្រូវលុបគេហទំព័រដើមដើម្បីបញ្ជាក់ backup ឬ?
មិនចាំបាច់ទេ។ ស្ដារចូលថតទទេដាច់ដោយឡែក ហើយពិនិត្យ manifest អាចសាក file copy ដោយមិនបង្ក outage ។ សាក service ទាំងមូលលើ replacement environment ផ្សេង។
Checksum ជោគជ័យមានន័យថាគេហទំព័រទាំងមូលត្រូវបាន backup ឬ?
វាបញ្ជាក់តែឯកសារក្នុង manifest ។ វាមិនអាចរក asset, database, secret ឬ DNS ដែលភ្លេចបញ្ចូល។ រក្សា inventory ហើយសាកមុខងារ site ពិតក្រោយ service restoration ។