Ubuntu VPS ಬ್ಯಾಕಪ್ ಮತ್ತು ಮರುಸ್ಥಾಪನೆ

ಸಣ್ಣ ಚೇತರಿಕೆ ವ್ಯಾಯಾಮವನ್ನು ವಿವರಿಸಿ

Ubuntu ಅಥವಾ Linux/WSL ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ Bash, GNU tar, sha256sum ಮತ್ತು OpenSSH ಅನ್ನು ಬಳಸಿ. ಸರ್ವರ್-ಲೇಬಲ್ ಮಾಡಲಾದ ಆಜ್ಞೆಗಳನ್ನು ಒಂದು ಸರ್ವರ್ ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಮತ್ತು ಕ್ಲೈಂಟ್-ಲೇಬಲ್ ಮಾಡಿದ ಆಜ್ಞೆಗಳನ್ನು ಒಂದು ಟರ್ಮಿನಲ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಿ. ಪ್ರತಿ ಟರ್ಮಿನಲ್ ಅನ್ನು ತೆರೆಯಿರಿ ಆದ್ದರಿಂದ ಅದರ ಅಸ್ಥಿರಗಳು ಲಭ್ಯವಿರುತ್ತವೆ. ಯಾವುದೇ ಆಜ್ಞೆಯ ದೋಷದ ನಂತರ ನಿಲ್ಲಿಸಿ.

ವ್ಯಾಯಾಮವು ನಿಮ್ಮ ಹೋಮ್ ಡೈರೆಕ್ಟರಿ ಅಡಿಯಲ್ಲಿ ಎರಡು ಬಿಸಾಡಬಹುದಾದ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಇದು Nginx, ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಅಥವಾ ಲೈವ್ ವಿಷಯವನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಮತ್ತು ಹೊರತೆಗೆಯುವಿಕೆ ಎಂದಿಗೂ ರೂಟ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಕೆಳಗಿನ ಫಿಕ್ಚರ್ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ; ಐಚ್ಛಿಕ ಪರ್ಯಾಯವು ಸ್ಟಾಟಿಕ್ HTTPS ನಿಯೋಜನೆ ವಾಕ್‌ಥ್ರೂ ನಿಂದ ಎರಡು ಫೈಲ್‌ಗಳನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತದೆ.

ಒಂದು ದೊಡ್ಡ ಸೈಟ್‌ಗಾಗಿ, ದಾಸ್ತಾನು ಅದರ ಸ್ವತ್ತುಗಳು, ಮರುನಿರ್ದೇಶನಗಳು, ಒಳಗೊಂಡಿರುವ ಸಂರಚನೆ, DNS ದಾಖಲೆಗಳು ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ. ಈ ಎರಡು-ಫೈಲ್ ಉದಾಹರಣೆಯು ಸಂಪೂರ್ಣ ಯಂತ್ರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಬ್ಯಾಕಪ್ ಅಲ್ಲ.

ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಎರಡು ಫೈಲ್‌ಗಳನ್ನು ತಯಾರಿಸಿ

ಸರ್ವರ್‌ನಲ್ಲಿ, ಖಾಸಗಿ ಅಭ್ಯಾಸ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಚಿಸಿ. ಕೆಳಗಿನ ಕಾನ್ಫಿಗರೇಶನ್ ಆರ್ಕೈವ್ ಮಾಡಲು ಫೈಲ್ ಆಗಿದೆ, ಸಕ್ರಿಯಗೊಳಿಸಲು ಸೇವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಅಲ್ಲ.

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"

ಐಚ್ಛಿಕ: ಬದಲಿಗೆ ಟ್ಯುಟೋರಿಯಲ್‌ನ ನೈಜ ಪುಟ ಮತ್ತು ಸರ್ವರ್ ಬ್ಲಾಕ್ ಅನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡಲು, ಕೆಳಗಿನ ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಬಿಸಾಡಬಹುದಾದ ಪ್ರತಿಗಳನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಿ. ಎರಡೂ ಮೂಲ ಫೈಲ್‌ಗಳನ್ನು ನಿಮ್ಮ ಖಾತೆಯಿಂದ ಓದಬಹುದಾಗಿದೆ. ಮೊದಲು ರಹಸ್ಯಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ನಿಯೋಜನೆಗಳನ್ನು ವಿರಾಮಗೊಳಿಸಿ ಆದ್ದರಿಂದ ಅವು ಒಂದೇ ಬಿಡುಗಡೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ಫಿಕ್ಸ್ಚರ್ ವ್ಯಾಯಾಮಕ್ಕಾಗಿ ಈ ಬ್ಲಾಕ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಿ.

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"

ಈ ಆಜ್ಞೆಗಳು ಲೈವ್ ಮೂಲಗಳನ್ನು ಮಾರ್ಪಡಿಸದೆಯೇ ಓದುತ್ತವೆ. ಅವರು ಪ್ರಮಾಣಪತ್ರ ಖಾಸಗಿ ಕೀಲಿಗಳನ್ನು ಅಥವಾ ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್ ಡೈರೆಕ್ಟರಿಗಳನ್ನು ನಕಲಿಸುವುದಿಲ್ಲ. ನಿಜವಾದ ಸೈಟ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಫೈಲ್‌ಗಳು ಬೇಕಾಗಬಹುದು; ದಾಸ್ತಾನು ಮತ್ತು ಚೆಕ್ಸಮ್ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಎರಡಕ್ಕೂ ಅವುಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸೇರಿಸಿ.

ಆರ್ಕೈವ್ ಮತ್ತು ಎರಡು ಹಂತದ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ರಚಿಸಿ

ಸರ್ವರ್‌ನಲ್ಲಿ, ಆಯ್ಕೆಮಾಡಿದ ಫೈಲ್‌ಗಳ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ, ಸಂಬಂಧಿತ ಮಾರ್ಗಗಳೊಂದಿಗೆ ಆರ್ಕೈವ್ ಅನ್ನು ರಚಿಸಿ, ನಂತರ ಆರ್ಕೈವ್ ಅನ್ನು ಚೆಕ್‌ಸಮ್ ಮಾಡಿ. ಈ ಹಂತದಲ್ಲಿ ಪೇಲೋಡ್ ಅನ್ನು ಬದಲಾಗದೆ ಇರಿಸಿ.

(
    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"

ಪಟ್ಟಿಯು ಸೈಟ್/, nginx/, ಆಯ್ಕೆಮಾಡಿದ ಎರಡು ಫೈಲ್‌ಗಳು ಮತ್ತು SHA256SUMS ಅನ್ನು ಒಳಗೊಂಡಿರಬೇಕು. ಆರ್ಕೈವ್ ಚೆಕ್ಸಮ್ ವರ್ಗಾವಣೆಗೊಂಡ ಆರ್ಕೈವ್ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ; ಆಂತರಿಕ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಹೊರತೆಗೆಯಲಾದ ಫೈಲ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಯಾರಾದರೂ ಡೇಟಾ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಚೆಕ್‌ಸಮ್ ಎರಡನ್ನೂ ಬದಲಾಯಿಸಬಹುದಾದರೆ ಚೆಕ್‌ಸಮ್ ಬ್ಯಾಕಪ್ ಅನ್ನು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ.

ಪ್ರತ್ಯೇಕ ಕಂಪ್ಯೂಟರ್‌ಗೆ ಬ್ಯಾಕಪ್ ಅನ್ನು ನಕಲಿಸಿ

ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ, ಸರ್ವರ್‌ನಿಂದ ಮುದ್ರಿಸಲಾದ ನಿಖರವಾದ ರಫ್ತು ಡೈರೆಕ್ಟರಿಗೆ ರಿಮೋಟ್_ಬ್ಯಾಕ್ಅಪ್ ಅನ್ನು ಹೊಂದಿಸಿ. ನಿಮ್ಮ ಕೆಲಸ ಮಾಡುವ 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/"

ಹೊಸ ಹೋಸ್ಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ವಿಶ್ವಾಸಾರ್ಹ ಚಾನಲ್ ಮೂಲಕ SSH ಹೋಸ್ಟ್ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. SSH ವಿಫಲವಾದ ಕಾರಣ ನಕಲು ವಿಫಲವಾದರೆ, SSH ದೋಷನಿವಾರಣೆ ಮಾರ್ಗದರ್ಶಿ ಅನ್ನು ಬಳಸಿ. ವರ್ಗಾವಣೆ ಯಶಸ್ವಿಯಾಗಲು ಹೋಸ್ಟ್-ಕೀ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಡಿ.

SCP SSH ಮೂಲಕ ವರ್ಗಾವಣೆಯನ್ನು ರಕ್ಷಿಸುತ್ತದೆ. tar.gz ಫೈಲ್ ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ, ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲಾಗಿಲ್ಲ: ಗಮ್ಯಸ್ಥಾನ ಖಾತೆ ಮತ್ತು ಸಂಗ್ರಹಣೆಯನ್ನು ರಕ್ಷಿಸಿ ಮತ್ತು ಡೇಟಾ ಅಗತ್ಯವಿರುವಾಗ ಉಳಿದಿರುವಾಗ ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಬಳಸಿ. ಅದೇ VPS ನಲ್ಲಿನ ಎರಡನೇ ಡೈರೆಕ್ಟರಿಯು ಆಫ್-ಸರ್ವರ್ ನಕಲನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ.

ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಹೊಸ ಖಾಲಿ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸಿ

ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ, ಮೊದಲು ಈ ವಿಶ್ವಾಸಾರ್ಹ ಆರ್ಕೈವ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಮ್ಯಾನಿಫೆಸ್ಟ್ ವಿರುದ್ಧ ಅದರ SHA-256 ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಅಸಾಮರಸ್ಯಕ್ಕೆ ತನಿಖೆ ಅಥವಾ ಹೊಸ ವರ್ಗಾವಣೆಯ ಅಗತ್ಯವಿದೆ; ನಿರೀಕ್ಷಿತ ಚೆಕ್ಸಮ್ ಅನ್ನು ಮರೆಮಾಚಲು ಎಂದಿಗೂ ತಿದ್ದಿ ಬರೆಯಬೇಡಿ.

(
    set -euo pipefail
    cd "$recovery_dir"
    sha256sum -c static-site.tar.gz.sha256
    tar -tzf static-site.tar.gz
)

ಪಟ್ಟಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ: ಇದು ಉದ್ದೇಶಿತ ಸೈಟ್/, nginx/ ಮತ್ತು ಚೆಕ್‌ಸಮ್ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಮಾತ್ರ ಹೊಂದಿರಬೇಕು. ಈ ವ್ಯಾಯಾಮಕ್ಕಾಗಿ, ನೀವು ಇದೀಗ ರಚಿಸಿದ ಆರ್ಕೈವ್ ಅನ್ನು ಮಾತ್ರ ಬಳಸಿ. ಆ ಪರಿಶೀಲನೆಯ ನಂತರ, ಕೆಳಗಿನ ಬ್ಲಾಕ್ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರಂತೆ ಹೊಸ ಖಾಲಿ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಹೊರತೆಗೆಯುತ್ತದೆ. ಇದು ಕಮಾಂಡ್ ದೋಷದಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಫೈಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಗುರಿಯನ್ನು ಬದಲಾಯಿಸಬೇಡಿ / ಅಥವಾ ಸುಡೋ ಸೇರಿಸಿ.

(
    set -euo pipefail
    cd "$recovery_dir"
    sha256sum -c static-site.tar.gz.sha256
    restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
    tar -xzf static-site.tar.gz -C "$restore_dir" \
        --keep-old-files --no-same-owner
    cd "$restore_dir"
    sha256sum -c SHA256SUMS
    cat site/index.html
    printf 'Recovered files: %s\n' "$restore_dir"
)

ಸೈಟ್/index.html ಮತ್ತು nginx/first-site.conf ಎರಡಕ್ಕೂ ಸರಿ ನಿರೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ಮರುಪಡೆಯಲಾದ ಪುಟದ ಶೀರ್ಷಿಕೆ. ಮುದ್ರಿತ ಡೈರೆಕ್ಟರಿ ಮಾರ್ಗವನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ: restore_dir ಈ ಬ್ಲಾಕ್‌ಗೆ ಸ್ಥಳೀಯವಾಗಿದೆ. ಇದು ಆಯ್ದ ಫೈಲ್ ಬೈಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಉತ್ಪಾದನಾ ಮಾಲೀಕತ್ವ, ACL ಗಳು, ಸೇವೆ ಲಭ್ಯತೆ ಅಥವಾ ಪ್ರತಿ ಅವಲಂಬನೆಯನ್ನು ಅಲ್ಲ. ಒಂದು ಬ್ಲಾಕ್ ವಿಫಲವಾದರೆ ನಿಲ್ಲಿಸಿ; ಒಂದು ಆಂಶಿಕ ಹೊರತೆಗೆಯುವಿಕೆ ಅಂಗೀಕಾರವಾದ ಚೇತರಿಕೆಯಲ್ಲ.

ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದರ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿ

ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಚೇತರಿಕೆಗೆ ವೆಬ್-ಡೈರೆಕ್ಟರಿ ಆರ್ಕೈವ್‌ಗಿಂತ ಹೆಚ್ಚಿನ ಅಗತ್ಯವಿದೆ. ಗುರಿಯನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು, ವಿಶ್ವಾಸಾರ್ಹ ಚೇತರಿಕೆ ಬಿಂದುವನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಕೆಳಗಿನ ದಾಸ್ತಾನುಗಳನ್ನು ಜೋಡಿಸಿ. ಅಗತ್ಯವಿರುವ ಭಾಗವು ಕಾಣೆಯಾಗಿದ್ದರೆ, ಅದನ್ನು ಪರಿಹರಿಸಲಾಗಿಲ್ಲ ಎಂದು ರೆಕಾರ್ಡ್ ಮಾಡಿ.

1. ಪಾಯಿಂಟ್ ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಗುರಿಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ಮಾತ್ರ ತಿಳಿದಿರುವ-ಒಳ್ಳೆಯ ಪ್ರತಿಯನ್ನು ಬದಲಾಗದೆ ಇರಿಸಿ. ವಿಶ್ವಾಸಾರ್ಹ ಮ್ಯಾನಿಫೆಸ್ಟ್ ವಿರುದ್ಧ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಹಳೆಯ VPS ಇಲ್ಲದೆಯೇ ನೀವು ನಕಲನ್ನು ಹಿಂಪಡೆಯಬಹುದು ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸಿ. ಮರುಸ್ಥಾಪಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮೇಲ್, ಪಾವತಿಗಳು, ವೆಬ್‌ಹೂಕ್‌ಗಳು ಅಥವಾ ಸರತಿಯಲ್ಲಿರುವ ಉದ್ಯೋಗಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ತಡೆಯಿರಿ.
2. ಪರಿಸರವನ್ನು ಮರುಸೃಷ್ಟಿಸಿ. ರೆಕಾರ್ಡ್ ಮಾಡಲಾದ ಹೊಂದಾಣಿಕೆಯ ರನ್‌ಟೈಮ್/ಡೇಟಾಬೇಸ್ ಆವೃತ್ತಿಗಳು ಮತ್ತು ಅಗತ್ಯವಿರುವ ವಿಸ್ತರಣೆಗಳನ್ನು ಸ್ಥಾಪಿಸಿ. ಉದ್ದೇಶಿತ ಬದಲಿ ಯಂತ್ರದಲ್ಲಿ ಬಳಕೆದಾರರು, ಮಾರ್ಗಗಳು ಮತ್ತು ಸೇವಾ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ತಯಾರಿಸಿ. ಆರ್ಕೈವ್, ಹೊರತೆಗೆಯಲಾದ ಫೈಲ್‌ಗಳು, ಡೇಟಾಬೇಸ್ ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಆಮದು ಕೆಲಸಕ್ಕಾಗಿ ಲಭ್ಯವಿರುವ ಸ್ಥಳವನ್ನು ಪರಿಶೀಲಿಸಿ.
3. ಸರಿಯಾದ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ. ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್‌ಗೆ ಆಮದು ಮಾಡಿ ಮತ್ತು ಹೊಂದಾಣಿಕೆಯ ಅಪ್ಲಿಕೇಶನ್ ಬಿಡುಗಡೆ ಮತ್ತು ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ಮರುಪಡೆಯಿರಿ. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಪ್ರತಿ ಆಮದು ದೋಷವನ್ನು ಪರಿಹರಿಸಿ.
4. ರಹಸ್ಯಗಳನ್ನು ಪೂರೈಸಿ ಮತ್ತು ಅನುಮತಿಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸಿ. ಅದರ ರಕ್ಷಿತ ಚಾನಲ್ ಮೂಲಕ ನಿರೀಕ್ಷಿತ ಅಪ್ಲಿಕೇಶನ್ ಕೀಯನ್ನು ಮರುಸ್ಥಾಪಿಸಿ. ಉದ್ದೇಶಪೂರ್ವಕ ಫೈಲ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಅನುಮತಿಗಳನ್ನು ನಿಯೋಜಿಸಿ; ವಿಶ್ವ-ಬರೆಯಬಹುದಾದ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ದೋಷಗಳನ್ನು ಪರಿಹರಿಸಬೇಡಿ.
5. ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಮೊದಲು ಮೌಲ್ಯೀಕರಿಸಿ. ಗುರಿಯ ಮೇಲೆ ಜೋಡಿಸಲಾದ Nginx ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ, ಅಗತ್ಯವಿರುವ ಸೇವೆಗಳನ್ನು ಮಾತ್ರ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ನೈಜ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಯಶಸ್ವಿ ಹೊರತೆಗೆಯುವಿಕೆ ಕೇವಲ ಒಂದು ಪೂರ್ಣಗೊಂಡ ಹಂತವಾಗಿದೆ.

ಸ್ಥಿರವಾದ ಡೇಟಾಬೇಸ್ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ

PostgreSQL ತಾರ್ಕಿಕ ಡಂಪ್

pg_dump ಒಂದು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿ ಸೆರೆಹಿಡಿಯುತ್ತದೆ; ಪಾತ್ರಗಳು ಮತ್ತು ಟೇಬಲ್ಸ್ಪೇಸ್ಗಳು ಪ್ರತ್ಯೇಕ ಕ್ಲಸ್ಟರ್ ವಸ್ತುಗಳು. ವಿಸ್ತರಣೆಗಳು ಮತ್ತು ಸವಲತ್ತುಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ. ಹೊಂದಾಣಿಕೆಯ ಡಂಪ್/ರಿಸ್ಟೋರ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿ: pg_dump ತನ್ನದೇ ಆದ ಹೊಸ ಸರ್ವರ್ ಪ್ರಮುಖ ಆವೃತ್ತಿಯನ್ನು ಓದಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಹಳೆಯ ಸರ್ವರ್ ಆವೃತ್ತಿಗೆ ಲೋಡ್ ಆಗುವುದನ್ನು ಖಾತರಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ತಾರ್ಕಿಕ ಡಂಪ್ ಮಾತ್ರ ನಿರಂತರ ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ಚೇತರಿಕೆಯಲ್ಲ.

SQLite

ಆನ್‌ಲೈನ್ ಬ್ಯಾಕಪ್ API (ಅದನ್ನು ಬಳಸುವ ಉಪಕರಣವನ್ನು ಒಳಗೊಂಡಂತೆ) ಅಥವಾ ಸ್ಥಿರವಾದ ಪ್ರತಿಗಾಗಿ VACUM INTO ಬಳಸಿ. ಕೋಲ್ಡ್ ಫೈಲ್ ನಕಲುಗಾಗಿ, ಎಲ್ಲಾ ಬರಹಗಾರರನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಜರ್ನಲ್/WAL ಸ್ಥಿತಿಯನ್ನು ಒಳಗೊಂಡಂತೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ದಾಖಲಿತ ವಿಧಾನವನ್ನು ಅನುಸರಿಸಿ. ಸಕ್ರಿಯ .db ಫೈಲ್ ಅನ್ನು ಮಾತ್ರ ನಕಲಿಸುವುದರಿಂದ ಬದ್ಧವಾಗಿರುವ ಡೇಟಾವನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸೂಚಿಸುವ ಮೊದಲು ಪ್ರತ್ಯೇಕ ಮಾರ್ಗವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ.

MySQL / MariaDB

ಎಂಜಿನ್‌ನ ಬೆಂಬಲಿತ ಡಂಪ್ ಟೂಲ್ ಅನ್ನು ಬಳಸಿ ಮತ್ತು ಅದರ ಆವೃತ್ತಿ, ಎಂಜಿನ್‌ಗಳು, ದಿನಚರಿಗಳು/ಈವೆಂಟ್‌ಗಳು, ಬಳಕೆದಾರರು/ಅನುದಾನಗಳು ಮತ್ತು ಇತರ ಅಗತ್ಯ ವಸ್ತುಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ. --ಏಕ-ವಹಿವಾಟು InnoDB ಗೆ ಸೂಕ್ತವಾಗಿದೆ, MyISAM/MEMORY ಅಥವಾ ಏಕಕಾಲೀನ ಸ್ಕೀಮಾ ಬದಲಾವಣೆಗಳಿಗೆ ಸ್ಥಿರತೆಯ ಗ್ಯಾರಂಟಿ ಅಲ್ಲ. ಬೆಂಬಲಿತ ಲಾಕ್/ಕ್ವೈಸ್ ವಿಧಾನದೊಂದಿಗೆ ಇತರ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಿ. ಪ್ರತ್ಯೇಕ ಗುರಿಯ ಮೇಲೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳುವ ಮೊದಲು ಡಂಪ್‌ನ ಡೇಟಾಬೇಸ್-ಸ್ವಿಚ್/ಡ್ರಾಪ್ ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ; ಪ್ರತಿಯೊಂದು SQL ಫೈಲ್ ಕಮಾಂಡ್ ಲೈನ್‌ನಲ್ಲಿ ಹೆಸರಿಸಲಾದ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ.

(
    set -euo pipefail
    test -s ./database.dump
    pg_restore --list ./database.dump
    createdb --template=template0 --owner=restoreapp restore_demo_check
    pg_restore --exit-on-error --single-transaction \
        --no-owner --no-acl --role=restoreapp \
        --dbname=restore_demo_check ./database.dump
)

ಚಾಲನೆಯಲ್ಲಿರುವ PostgreSQL/MySQL ಡೇಟಾ ಡೈರೆಕ್ಟರಿಯನ್ನು ನಕಲಿಸಲು ಮೇಲಿನ ಫೈಲ್ ವ್ಯಾಯಾಮವನ್ನು ಬಳಸಬೇಡಿ. ಭೌತಿಕ ಬ್ಯಾಕ್‌ಅಪ್‌ಗಳು, ಪೂರ್ಣ-ಡಿಸ್ಕ್ ಇಮೇಜ್ಗಳು ಮತ್ತು ಪಾಯಿಂಟ್-ಇನ್-ಟೈಮ್ ಮರುಪಡೆಯುವಿಕೆಗೆ ತಮ್ಮದೇ ಆದ ಎಂಜಿನ್/ಪ್ರೊವೈಡರ್ ಕಾರ್ಯವಿಧಾನಗಳು ಬೇಕಾಗುತ್ತವೆ. OS ಆಯ್ಕೆಗಾಗಿ, Ubuntu ಹೊಂದಾಣಿಕೆ ಮಾರ್ಗದರ್ಶಿ ಬಳಸಿ; ಮೂಲ ವೆಬ್ ಸರ್ವರ್‌ಗಾಗಿ, ನಿಯೋಜನೆ ವಾಕ್‌ಥ್ರೂ ಅನ್ನು ಬಳಸಿ.

ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುವ ಮೊದಲು ಸೇವೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಉದ್ದೇಶಿತ ಅಪ್ಲಿಕೇಶನ್ ಬಿಡುಗಡೆ ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಿದ ಡೇಟಾದೊಂದಿಗೆ ಪ್ರತ್ಯೇಕವಾದ ಬದಲಿ ಪರೀಕ್ಷೆ. ಹಳೆಯ ಮೂಲ ಮತ್ತು ತಿಳಿದಿರುವ-ಉತ್ತಮ ಬ್ಯಾಕಪ್ ಅನ್ನು ಹಾಗೆಯೇ ಇರಿಸಿ. ಪ್ರತಿ ಫಲಿತಾಂಶವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ; ಸಕ್ರಿಯ ಎಂದು ಗುರುತಿಸಲಾದ ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಜೆನೆರಿಕ್ HTTP 200 ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಪುರಾವೆಯಾಗಿಲ್ಲ.

1. ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಪ್ರಾರಂಭ: ಗುರಿ Nginx ಕಾನ್ಫಿಗರೇಶನ್, ಅಗತ್ಯವಿರುವ ಸೇವೆಗಳು, ರನ್ಟೈಮ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ. ಪದೇ ಪದೇ ಮರುಪ್ರಾರಂಭಿಸುವ ಬದಲು ಆರಂಭಿಕ ದೋಷಗಳನ್ನು ಓದಿ.
2. Data ಮತ್ತು ಅನುಮತಿಗಳು: ನಿರೀಕ್ಷಿತ ರಿಕವರಿ ಪಾಯಿಂಟ್, ಪ್ರಾತಿನಿಧಿಕ ದಾಖಲೆಗಳು, ಸಾಲು ಎಣಿಕೆಗಳು/ಚೆಕ್‌ಸಮ್‌ಗಳು ಲಭ್ಯವಿರುವಲ್ಲಿ, ಅಪ್‌ಲೋಡ್‌ಗಳು ಮತ್ತು ಅಗತ್ಯವಿರುವ ಫೈಲ್ ಮಾಲೀಕತ್ವವನ್ನು ಹೋಲಿಸುತ್ತದೆ. ಲಾಗಿನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅನಧಿಕೃತ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರಾಕರಿಸಲಾಗಿದೆ.
3. ಅಪ್ಲಿಕೇಶನ್ ನಡವಳಿಕೆ: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಡೇಟಾವನ್ನು ಓದಿ, ನಿರುಪದ್ರವ ಪರೀಕ್ಷಾ ದಾಖಲೆಯನ್ನು ರಚಿಸಿ ಮತ್ತು ಹಿಂಪಡೆಯಿರಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ಬಳಸಿದರೆ ಅಪ್‌ಲೋಡ್ ಅನ್ನು ವ್ಯಾಯಾಮ ಮಾಡಿ. ನಿಯಂತ್ರಿತ ಪರೀಕ್ಷಾ ಕೆಲಸದೊಂದಿಗೆ ಕೆಲಸಗಾರರನ್ನು ಪರಿಶೀಲಿಸಿ; ಪರೀಕ್ಷಿಸುವಾಗ ಹೊರಹೋಗುವ ಮೇಲ್, ಪಾವತಿಗಳು ಮತ್ತು ನೈಜ ವೆಬ್‌ಹೂಕ್‌ಗಳನ್ನು ನಿರ್ಬಂಧಿಸಿ.
4. Persistence: ಯೋಜಿತ ಮರುಪ್ರಾರಂಭದ ನಂತರ ಅಥವಾ ಪ್ರತ್ಯೇಕ ಗುರಿಯನ್ನು ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ, ಸೇವಾ ಪ್ರಾರಂಭ ಮತ್ತು ಪರೀಕ್ಷಾ ದಾಖಲೆಯನ್ನು ಮತ್ತೊಮ್ಮೆ ಪರಿಶೀಲಿಸಿ. ಈ ಚೆಕ್ ಅನ್ನು ನಕಲಿಸಲು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್ ಅನ್ನು ರೀಬೂಟ್ ಮಾಡಬೇಡಿ.
5. Hostname ಮತ್ತು HTTPS: DNS ಬದಲಾಯಿಸುವ ಮೊದಲು ಬದಲಿ ವಿರುದ್ಧ ಉದ್ದೇಶಿತ ಡೊಮೇನ್, ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ನಿಜವಾದ ಪ್ರತಿಕ್ರಿಯೆ ದೇಹವನ್ನು ಪರಿಶೀಲಿಸಿ. IPv4/IPv6 ದಾಖಲೆಗಳು ಮತ್ತು ಪ್ರಾಕ್ಸಿ/CDN ರೂಟಿಂಗ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ.
6. Cutover: ಅಂತಿಮ ಸ್ಥಿರವಾದ ನಕಲು ಮತ್ತು ಬರಹ-ಫ್ರೀಜ್/ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಯೋಜನೆಯನ್ನು ಒಪ್ಪುತ್ತದೆ. ಚೆಕ್ ಪಾಸ್ ಆದ ನಂತರವೇ ಬದಲಿಸಿ; ನೈಜ ವಿನಂತಿಗಳು ಮತ್ತು ಉದ್ಯೋಗಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ಒಂದು ಉದ್ದೇಶಿತ ಪರಿಸರದಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಗದಿತ ಕೆಲಸವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ.

curl --noproxy '*' --fail --show-error --silent \
    --connect-timeout 10 --max-time 20 \
    --resolve example.com:443:203.0.113.10 \
    https://example.com/

ಮರುಪ್ರಾಪ್ತಿ ಪರಿಶೀಲನೆ ವಿಫಲವಾದಾಗ

ಪರಿಶೀಲಿಸಿದ, ಇತ್ತೀಚಿನ ಚೇತರಿಕೆಯ ಬಿಂದುವನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ

RPO ಡೇಟಾ ನಷ್ಟದ ನಿಮ್ಮ ಸಹಿಸಿಕೊಳ್ಳುವ ಸಮಯ ವಿಂಡೋ ಆಗಿದೆ. RTO ಸೇವೆಯನ್ನು ಮರುಪಡೆಯಲು ನಿಮ್ಮ ಗುರಿ ಸಮಯ. ಅಪ್ಲಿಕೇಶನ್ಗಾಗಿ ಅವುಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ; ದೈನಂದಿನ ವೇಳಾಪಟ್ಟಿ ಮತ್ತು ವೇಗದ ಹೊರತೆಗೆಯುವಿಕೆ ಎರಡೂ ಫಲಿತಾಂಶವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ.

1. ಸ್ಥಿರವಾಗಿ ಕ್ಯಾಪ್ಚರ್ ಮಾಡಿ. ಡೇಟಾ ಪಾಯಿಂಟ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಬಿಡುಗಡೆಯನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ; ಡೇಟಾಬೇಸ್ ಮತ್ತು ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ಸಂಘಟಿಸಿ.
2. ಸೆರೆಹಿಡಿಯಲಾದ ಸೆಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ಪೂರ್ಣಗೊಳಿಸುವಿಕೆ, ನಿರೀಕ್ಷಿತ ದಾಸ್ತಾನು ಮತ್ತು ಸಮಗ್ರತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಫೈಲ್ ಅನ್ನು ರಚಿಸಿದ್ದರೂ ಸಹ ವಿಫಲವಾದ ಅಥವಾ ಅಪೂರ್ಣ ಕೆಲಸವನ್ನು ವಿಫಲವಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ.
3. ಸ್ವತಂತ್ರ ಪ್ರತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಮೂಲ ಯಂತ್ರವಿಲ್ಲದೆ ಅದನ್ನು ಹಿಂಪಡೆಯಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪ್ರತ್ಯೇಕ ಪ್ರವೇಶ/ಖಾತೆ ಅವಲಂಬನೆಗಳನ್ನು ಪರಿಗಣಿಸಿ; ಅದೇ VPS ನಲ್ಲಿ ಮತ್ತೊಂದು ಫೋಲ್ಡರ್ ಸ್ವತಂತ್ರ ಸಂಗ್ರಹಣೆಯಲ್ಲ.
4. ಗಮ್ಯಸ್ಥಾನವನ್ನು ದೃಢೀಕರಿಸಿ. ಉದ್ದೇಶಿತ ಪ್ರತಿ ಬಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಓದಬಹುದು ಮತ್ತು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು. ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಕ್ಷಿತ ಚಾನಲ್ ಮೂಲಕ ಲಭ್ಯವಿರುವ ಮರುಪ್ರಾಪ್ತಿ ಕೀಲಿಯನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ.
5. ಯಶಸ್ಸನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಇತಿಹಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಮಾತ್ರ ಪೂರ್ಣಗೊಂಡ, ಪರಿಶೀಲಿಸಿದ ಸರಪಳಿಯು ಯಶಸ್ವಿ ಚೇತರಿಕೆಯ ಬಿಂದುವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ. ಪರಿಶೀಲಿಸಲಾದ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಧಾರಣವನ್ನು ರನ್ ಮಾಡಿ, ಬಳಸಬಹುದಾದ ಪ್ರತಿಗಳನ್ನು ಸಂರಕ್ಷಿಸಿ; ವಿಫಲವಾದ ಹೊಸ ಓಟವು ಕೊನೆಯ ಉತ್ತಮವಾದ ಕುರುಡು ತೆಗೆಯುವಿಕೆಯನ್ನು ಪ್ರಚೋದಿಸಬಾರದು.
6. ಮಾನಿಟರ್ ಮತ್ತು ಪೂರ್ವಾಭ್ಯಾಸ. ವಿಫಲವಾದ ಉದ್ಯೋಗಗಳು, ಹಳೆಯ ಪರಿಶೀಲಿಸಿದ ಅಂಕಗಳು ಮತ್ತು ಶೇಖರಣಾ ಸಮಸ್ಯೆಗಳ ಕುರಿತು ಎಚ್ಚರಿಕೆ. ನಿಯತಕಾಲಿಕವಾಗಿ ಪ್ರತಿನಿಧಿ ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ ಮತ್ತು ಸೇವೆಯನ್ನು ಚಲಾಯಿಸಿ.

ಪೂರ್ಣ ಚೇತರಿಕೆ ಮಧ್ಯಂತರ, ದಾಖಲೆ ಪ್ರವೇಶ ಮರುಪಡೆಯುವಿಕೆ, ಗುರಿ ಒದಗಿಸುವಿಕೆ, ಪರಿಸರ ಸೆಟಪ್, ವರ್ಗಾವಣೆ, ಆಮದು, ಮೌಲ್ಯೀಕರಣ ಮತ್ತು ಯಾವುದೇ DNS/TLS ಕೆಲಸಕ್ಕಾಗಿ. ನಿಮ್ಮ RTO ನೊಂದಿಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಮಧ್ಯಂತರವನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ; ಆರ್ಕೈವ್ ಹೊರತೆಗೆಯುವ ಸಮಯವನ್ನು ಮಾತ್ರ ಬದಲಿಸಬೇಡಿ. ಸಂಗ್ರಹಣೆ ಅಥವಾ ಪೂರೈಕೆದಾರರನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ hosting ಬ್ಯಾಕ್‌ಅಪ್ ಮತ್ತು ಚೇತರಿಕೆಯ ಪರಿಸ್ಥಿತಿಗಳು ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ.

ನಾವು ನಿಜವಾಗಿ ಏನನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ್ದೇವೆ

ಇವುಗಳು ನಿರ್ದಿಷ್ಟ ಮರುಪಡೆಯುವಿಕೆ ಡ್ರಿಲ್‌ಗಳಿಂದ ಉಳಿಸಿದ ಫಲಿತಾಂಶಗಳಾಗಿವೆ, ಒದಗಿಸುವವರ ವೇಗದ ಶ್ರೇಯಾಂಕ ಅಥವಾ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಭರವಸೆಯಲ್ಲ.

Ubuntu ಅಪ್ಲಿಕೇಶನ್ + PostgreSQL: ಕ್ಲೀನ್ ರಿಪ್ಲೇಸ್ಮೆಂಟ್ VM

9 ಅಕ್ಟೋಬರ್ 2026ರಂದು ಪರೀಕ್ಷೆಗಾಗಿ ರಚಿಸಿದ Python ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು PostgreSQL ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ, ಸ್ವಚ್ಛ Ubuntu 24.04.5 LTS VM ನಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸಲಾಯಿತು. ಮರುಸ್ಥಾಪನೆಗೂ ಮೊದಲು ಮೂಲ VM ನಿಲ್ಲಿಸಲಾಗಿತ್ತು; ಎರಡೂ VM ಗಳ machine ID ಬೇರೆಬೇರೆಯಾಗಿದ್ದವು. ಗುರಿ ಸರ್ವರ್‌ನಲ್ಲಿ Python 3.12.3, PostgreSQL 16.15 ಮತ್ತು Nginx 1.24 ಬಳಸಲಾಗಿತ್ತು.

• Data: 1,001 ಡೇಟಾಬೇಸ್ ಸಾಲುಗಳು ಮತ್ತು 3 ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳನ್ನು ಮರುಪಡೆಯಲಾಗಿದೆ; ಡೇಟಾ, ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅಪ್‌ಲೋಡ್ ಹ್ಯಾಶ್‌ಗಳು ಮತ್ತು ನಿರೀಕ್ಷಿತ ಫೈಲ್ ಅನುಮತಿಗಳು ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತವೆ.
• ಋಣಾತ್ಮಕ ಪರಿಶೀಲನೆಗಳು: ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಭ್ರಷ್ಟಗೊಂಡ ಆರ್ಕೈವ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ; ಆ ಚೇತರಿಕೆಯ ಹಂತಕ್ಕೆ ನಿರೀಕ್ಷಿಸಿದಂತೆ ಬ್ಯಾಕಪ್ ಇಲ್ಲದ ನಂತರ ಮಾಡಿದ ಮೂಲ ಬರಹ.
• ವರ್ಕಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್: 11 HTTP ಚೆಕ್‌ಗಳು ಓದುವಿಕೆ, ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳು, ಅನಧಿಕೃತ ಬರವಣಿಗೆಯ ನಿರಾಕರಣೆ ಮತ್ತು ಯಶಸ್ವಿ ಹೊಸ ವಹಿವಾಟನ್ನು ಒಳಗೊಂಡಿವೆ.
• ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ: ಹೊಸ ವಹಿವಾಟು (ID 1002) ಉಳಿಯಿತು ಮತ್ತು ಸೇವೆಗಳು ಪ್ರಾರಂಭವಾದವು. ಅಪ್ಲಿಕೇಶನ್ ರಹಸ್ಯವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಒದಗಿಸಲಾಗಿದೆ, ಆರ್ಕೈವ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿಲ್ಲ.

Ubuntu ಓದಿ + PostgreSQL ಪರಿಶೀಲನೆ ದಾಖಲೆ (JSON) →

ನಿಮ್ಮ ಮರುಪ್ರಾಪ್ತಿ ಯೋಜನೆ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಉಳಿಸಿ

ಒಂದು ನಕಲು, ಒಂದು ಬದಲಿ ಗುರಿ ಮತ್ತು ನೀವು ನಿಜವಾಗಿ ನಿರ್ವಹಿಸಿದ ತಪಾಸಣೆಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ. ಉಪಕರಣವು ನಿಮ್ಮ VPS ಗೆ ಸಂಪರ್ಕಗೊಂಡಿಲ್ಲ. ನೀವು ಉಳಿಸು ಆಯ್ಕೆ ಮಾಡಿದಾಗ ಮಾತ್ರ ಇದು ಉಳಿಸುತ್ತದೆ; ನಿಮ್ಮ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ರಫ್ತು ಮತ್ತು ಆಮದುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ಟೋಕನ್‌ಗಳು, ಖಾಸಗಿ ಕೀಗಳು ಮತ್ತು ಗೌಪ್ಯ ಲಾಗ್‌ಗಳನ್ನು ಪ್ರತಿಯೊಂದು ಕ್ಷೇತ್ರದಿಂದ ಹೊರಗಿಡಿ.

ನಕಲು, ವ್ಯಾಪ್ತಿ, ಗುರಿ ಅಥವಾ ದಾಸ್ತಾನು ಮರುಹೊಂದಿಸುವ ಹಿಂದಿನ ಚೆಕ್ ಗುರುತುಗಳನ್ನು ಬದಲಾಯಿಸುವುದು. ಉಳಿಸಿದ/ಆಮದು ಮಾಡಿಕೊಂಡ ಅಂಕಗಳು ಹಿಂದಿನ ಅವಲೋಕನಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ; ಅವು ಇನ್ನೂ ಅನ್ವಯಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಮೆಷಿನ್-ಇಮೇಜ್ ಚೆಕ್‌ಲಿಸ್ಟ್‌ಗಳು ಡೇಟಾಬೇಸ್-ಬೆಂಬಲಿತ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿವೆ; ಫೈಲ್-ಮಾತ್ರ ಡ್ರಿಲ್‌ಗಾಗಿ ಆಯ್ಕೆಮಾಡಿದ-ಫೈಲ್ ಸ್ಕೋಪ್ ಅನ್ನು ಬಳಸಿ.

ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಉತ್ತರಗಳು

ಮೂಲಗಳು ಮತ್ತು ಪರಿಶೀಲನೆ

ಉಲ್ಲೇಖ ವಸ್ತು: Ubuntu ಸರ್ವರ್ ಬ್ಯಾಕಪ್ ದಾಖಲಾತಿ; GNU tar ಮತ್ತು Coreutils ಕೈಪಿಡಿಗಳು; OpenSSH scp ಕೈಪಿಡಿ; PostgreSQL 16 pg_dump ಮತ್ತು pg_restore ದಸ್ತಾವೇಜನ್ನು; SQLite ಆನ್‌ಲೈನ್ ಬ್ಯಾಕಪ್ API; MySQL 8.4 mysqldump ಮತ್ತು MariaDB mariadb-dump ಕೈಪಿಡಿಗಳು; ರೆಸ್ಟಿಕ್ ರೆಪೊಸಿಟರಿ - ದಾಖಲೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಮರುಸ್ಥಾಪಿಸಿ; ಕರ್ಲ್ ಸಂಪರ್ಕ-ರೆಸಲ್ಯೂಶನ್ ದಸ್ತಾವೇಜನ್ನು; n8n CLI ದಸ್ತಾವೇಜನ್ನು.

ಡೇಟಾಬೇಸ್ ಮತ್ತು ಸಂಪರ್ಕ-ಪರಿಶೀಲನೆ ಉಲ್ಲೇಖಗಳನ್ನು 13 ಅಕ್ಟೋಬರ್ 2026 ರಂದು ಪರಿಶೀಲಿಸಲಾಗಿದೆ. ಪ್ರಕಟಿಸಿದ ಕಮಾಂಡ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬ್ಯಾಷ್ ಸಿಂಟ್ಯಾಕ್ಸ್‌ಗಾಗಿ ಪರಿಶೀಲಿಸಲಾಗಿದೆ; ಸಂದರ್ಶಕರ VPS ವಿರುದ್ಧ ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿಲ್ಲ. ಹಿಂದಿನ ಫಿಕ್ಚರ್ ವ್ಯಾಯಾಮವು ವಿಂಡೋಸ್‌ನಲ್ಲಿನ Git Bash ನಲ್ಲಿ GNU ಉಪಕರಣಗಳನ್ನು ಬಳಸಿತು. ಪ್ರತ್ಯೇಕ ಐತಿಹಾಸಿಕ Ubuntu/PostgreSQL, n8n ಮತ್ತು ಸ್ಟ್ಯಾಟಿಕ್-ಫೈಲ್ ಡ್ರಿಲ್‌ಗಳನ್ನು our ಪರಿಶೀಲನಾ ದಾಖಲೆಗಳಲ್ಲಿ , ಅವುಗಳ ನಿಖರವಾದ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಮಿತಿಗಳೊಂದಿಗೆ ವಿವರಿಸಲಾಗಿದೆ.

ರಿಕವರಿ ಹಂತಗಳು ನಿಜವಾದ ಎಂಜಿನ್, ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಪೂರೈಕೆದಾರರಿಗೆ ಸರಿಹೊಂದಬೇಕು. ಈ ಮಾರ್ಗದರ್ಶಿಯು ಅಪೂರ್ಣ ನಕಲನ್ನು ಮರುಪಡೆಯಲು ಭರವಸೆ ನೀಡುವುದಿಲ್ಲ ಅಥವಾ ಸ್ಥಗಿತದ ಅವಧಿಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.