VPS Backup ਅਤੇ ਰੀਸਟੋਰ ਦੀ ਅਮਲੀ ਜਾਂਚ ਕਰੋ

ਛੋਟੀ recovery ਕਸਰਤ ਦੀ ਹੱਦ ਤੈਅ ਕਰੋ

Bash, GNU tar, sha256sum ਅਤੇ OpenSSH ਵਰਤੋ। Server commands ਇੱਕ ਸਰਵਰ terminal ਅਤੇ client commands ਵੱਖਰੇ Ubuntu/Linux/WSL ਕੰਪਿਊਟਰ ਦੇ terminal ਵਿੱਚ ਚਲਾਓ। Variables ਬਚਾਉਣ ਲਈ ਦੋਵੇਂ ਖੁੱਲ੍ਹੇ ਰੱਖੋ; ਕਿਸੇ command ਦੀ ਗ਼ਲਤੀ ਉੱਤੇ ਰੁਕੋ।

ਕਸਰਤ home directory ਵਿੱਚ ਦੋ ਅਸਥਾਈ ਫ਼ਾਈਲਾਂ ਵਰਤਦੀ ਹੈ। Nginx, firewall ਜਾਂ live content ਨਹੀਂ ਬਦਲਦਾ ਅਤੇ extraction root ਵਜੋਂ ਨਹੀਂ ਹੁੰਦੀ। ਵੱਡੀ ਸਾਈਟ ਲਈ assets, redirects, includes, DNS ਅਤੇ dependencies ਦੀ ਵੱਖ inventory ਚਾਹੀਦੀ ਹੈ; ਇਹ ਪੂਰੀ machine ਦੀ Backup ਨਹੀਂ।

ਚੱਲਦੀ ਸਾਈਟ ਬਦਲੇ ਬਿਨਾਂ ਦੋ ਫ਼ਾਈਲਾਂ ਬਣਾਓ

ਸਰਵਰ ਉੱਤੇ private practice directory ਬਣਾਓ। ਇਹ configuration archive ਕਰਨ ਲਈ text file ਹੈ, 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"

ਚਾਹੋ ਤਾਂ HTTPS ਗਾਈਡ ਦੀਆਂ ਸਿਰਫ਼ ਦੋ ਅਸਲ ਫ਼ਾਈਲਾਂ disposable copies ਦੀ ਥਾਂ ਰੱਖੋ। ਦੋਵੇਂ readable ਹੋਣ ਅਤੇ secrets ਜਾਂਚੇ ਹੋਣ। ਇੱਕੋ release ਮਿਲੇ ਇਸ ਲਈ collection ਵੇਲੇ deployment ਰੋਕੋ। ਸਿਰਫ਼ ਬਣਾਈਆਂ example files ਲਈ ਹੇਠਲਾ optional ਬਲਾਕ ਛੱਡੋ।

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 ਕਾਪੀ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਹੋਰ ਲੋੜੀਂਦੀਆਂ ਫ਼ਾਈਲਾਂ inventory ਅਤੇ checksum manifest ਦੋਹਾਂ ਵਿੱਚ ਜਾਣ-ਬੁੱਝ ਕੇ ਜੋੜੋ।

Archive ਅਤੇ ਦੋ ਪੱਧਰਾਂ ਦੇ checksums ਬਣਾਓ

ਸਰਵਰ ਉੱਤੇ ਫ਼ਾਈਲਾਂ ਦੇ checksums ਲਿਖੋ, relative paths ਨਾਲ archive ਬਣਾਓ ਅਤੇ archive ਦਾ checksum ਲਵੋ। ਇਸ ਦੌਰਾਨ 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"

Listing ਵਿੱਚ site/, nginx/, ਦੋ ਚੁਣੀਆਂ ਫ਼ਾਈਲਾਂ ਅਤੇ SHA256SUMS ਹੋਣ। ਬਾਹਰਲਾ checksum transfer ਦੀ ਅਤੇ ਅੰਦਰਲਾ extracted bytes ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇ ਕੋਈ data ਅਤੇ expected checksum ਦੋਵੇਂ ਬਦਲ ਸਕੇ ਤਾਂ ਇਹ ਆਪਣੇ ਆਪ authenticity ਨਹੀਂ ਦਿੰਦਾ।

Backup ਹੋਰ ਕੰਪਿਊਟਰ ਉੱਤੇ ਲਵੋ

ਆਪਣੇ client ਉੱਤੇ remote_backup ਨੂੰ server ਵੱਲੋਂ ਛਾਪੇ exact export directory ਨਾਲ ਸੈੱਟ ਕਰੋ। IP, account ਅਤੇ key ਆਪਣੀ ਕੰਮ ਕਰਦੀ ਪਹੁੰਚ ਨਾਲ ਬਦਲੋ। REPLACE ਅਸਥਾਈ placeholder ਹੈ, 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/"

ਨਵੀਂ SSH host key trusted ਰਸਤੇ ਨਾਲ ਜਾਂਚੋ। Transfer ਦੀ ਸਮੱਸਿਆ ਲਈ SSH diagnosis ਵਰਤੋ; host-key checking ਬੰਦ ਨਾ ਕਰੋ।

SCP transfer ਨੂੰ SSH ਨਾਲ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ। tar.gz ਖ਼ੁਦ compressed ਹੈ, encrypted ਨਹੀਂ। Destination account/storage ਸੁਰੱਖਿਅਤ ਰੱਖੋ ਅਤੇ ਲੋੜ ਹੋਵੇ ਤਾਂ encryption at rest ਵਰਤੋ। ਉਸੇ VPS ਦਾ ਹੋਰ ਫੋਲਡਰ off-server copy ਨਹੀਂ ਹੈ।

ਖਾਲੀ ਨਵੇਂ ਫੋਲਡਰ ਵਿੱਚ restore ਜਾਂਚੋ

Client ਉੱਤੇ archive checksum ਜਾਂਚੋ। OK ਆਉਣ ਉੱਤੇ ਹੀ ਅੱਗੇ ਜਾਓ। Failure ਨੂੰ ਲੁਕਾਉਣ ਲਈ expected checksum ਨਾ ਬਦਲੋ।

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

Trusted archive ਨੂੰ ਨਵੇਂ ਖਾਲੀ directory ਵਿੱਚ ਕੱਢੋ। keep-old-files ਮੌਜੂਦਾ ਫ਼ਾਈਲਾਂ ਉੱਤੇ ਨਹੀਂ ਲਿਖਦਾ ਅਤੇ no-same-owner ਪੁਰਾਣੀ ownership ਨਹੀਂ ਲਗਾਉਂਦਾ। Destination ਨੂੰ / ਨਾ ਬਣਾਓ ਅਤੇ sudo ਨਾਲ extract ਨਾ ਕਰੋ।

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"

site/index.html ਅਤੇ nginx/first-site.conf ਦੋਹਾਂ ਲਈ OK ਅਤੇ ਪੰਨੇ ਦਾ ਉਮੀਦ ਵਾਲਾ ਸਿਰਲੇਖ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ bytes ਜਾਂਚਦਾ ਹੈ, production ownership, ACLs ਜਾਂ ਪੂਰੀ service ਨਹੀਂ।

ਫ਼ਾਈਲ ਅਤੇ service recovery ਵੱਖ ਜਾਂਚੋ

ਬਹਾਲ configuration ਅਜੇ inactive text file ਹੈ। ਵੱਖਰੇ replacement server ਉੱਤੇ paths, includes, modules, permissions ਅਤੇ certificates ਮਿਲਾਕੇ ਪੂਰੀ Nginx configuration validate ਕਰੋ। ਫਿਰ reload ਅਤੇ ਬਾਹਰੀ HTTP/HTTPS ਜਾਂਚੋ। ਪੁਰਾਣੇ live server ਦਾ syntax check restored copy ਦੀ ਜਾਂਚ ਨਹੀਂ ਹੈ।

TLS private keys ਇਸ archive ਵਿੱਚ ਨਹੀਂ ਹਨ; reissue ਜਾਂ ਵੱਖਰੀ ਸੁਰੱਖਿਅਤ certificate Backup ਦੀ ਯੋਜਨਾ ਬਣਾਓ। Active database files ਨੂੰ ਇਸ tar ਵਿਧੀ ਨਾਲ ਨਾ ਕਾਪੀ ਕਰੋ; database ਦਾ supported consistent Backup/restore ਵਰਤੋ। Snapshot ਦੀ retention ਅਤੇ restore ਵਿਧੀ ਵੀ ਵੱਖ ਜਾਂਚੋ।

Recovery ਦਾ ਟੀਚਾ ਅਤੇ ਅਸਲ ਨਤੀਜਾ ਦਰਜ ਕਰੋ

RPO ਸਮੇਂ ਵਿੱਚ ਮਨਜ਼ੂਰ data loss ਅਤੇ RTO service ਮੁੜ ਚਲਾਉਣ ਦਾ target ਸਮਾਂ ਹੈ। ਛੋਟੀ static site ਲਈ 24-hour RPO ਅਤੇ 60-minute RTO ਸਿਰਫ਼ ਉਦਾਹਰਨ ਦੇ ਕਾਰੋਬਾਰੀ ਟੀਚੇ ਹਨ, ਮਾਪੇ ਨਤੀਜੇ ਨਹੀਂ। Daily Backup ਤਦ ਹੀ ਮਦਦ ਕਰਦੀ ਹੈ ਜੇ ਸਫਲ ਅਤੇ recoverable ਹੋਵੇ।

ਛੋਟੀ ਸਕ੍ਰੀਨ ਉੱਤੇ ਸਾਰੇ ਕਾਲਮ ਵੇਖਣ ਲਈ ਸਾਰਣੀ ਪਾਸੇ ਵੱਲ ਖਿਸਕਾਓ।

RTO ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ access, provisioning, configuration, certificate ਅਤੇ ਲੋੜੀਂਦੇ DNS ਸਮੇਤ ਪੂਰੀ recovery ਦਾ ਸਮਾਂ ਮਾਪੋ। ਤੇਜ਼ extraction outage benchmark ਨਹੀਂ। ਕਈ restore points ਅਤੇ failed jobs ਦੀ ਜਾਂਚ ਰੱਖੋ। ਹੋਸਟਿੰਗ recovery ਦੀਆਂ ਸ਼ਰਤਾਂ ਨਾਲ ਮਿਲਾਓ।

ਸਵਾਲ ਜਵਾਬ

ਦਸਤਾਵੇਜ਼ ਅਤੇ ਹਵਾਲੇ

• ਦਸਤਾਵੇਜ਼: Ubuntu shell-script backup and restoration
• ਦਸਤਾਵੇਜ਼: GNU tar manual and extraction safety
• ਦਸਤਾਵੇਜ਼: GNU Coreutils checksum documentation
• ਦਸਤਾਵੇਜ਼: OpenSSH secure copy manual