సరిగ్గా ఏమి కాపీ చేయాలి

మేము మీ మెషీన్ యొక్క ఆటోమేటిక్ బ్యాకప్‌లను తయారు చేయము: ప్యానెల్‌లో స్టేట్ స్నాప్‌షాట్‌లు కూడా ఉండవు, మరియు OSని మళ్లీ ఇన్‌స్టాల్ చేయడం డిస్క్‌ను పూర్తిగా తుడిచివేస్తుంది. అంటే బ్యాకప్‌లు పూర్తిగా మీ బాధ్యత, మరియు మీరు నష్టం జరిగిన తర్వాత కాదు, మొదటి రోజు నుండే ప్రారంభించాలి.

మీరు తప్పనిసరిగా బ్యాకప్ చేయాల్సినవి

• అప్లికేషన్ డేటా — Docker వాల్యూమ్‌లు, సైట్ డైరెక్టరీలు, యూజర్ అప్‌లోడ్ చేసిన ఫైల్‌లు.
• డేటాబేస్ డంప్‌లు — ప్రత్యేకంగా డంప్‌లు, లైవ్ డేటాబేస్ ఫైల్‌లు కాదు (దీని గురించి క్రింద మరింత ఉంది).
• కాన్ఫిగరేషన్ — /etc/nginx, /etc/caddy, systemd యూనిట్‌లు, compose.yaml మరియు .env ఫైల్‌లు, ఫైర్‌వాల్ నియమాలు.
• సర్టిఫికెట్‌లు మరియు కీలు — /etc/letsencrypt, అప్లికేషన్ కీలు, మెయిల్ సర్వర్ DKIM కీలు.
• షెడ్యూల్ చేసిన జాబ్‌లు — బ్యాకప్ చేయడానికి ముందు crontab -l > /root/crontab.txt, లేకపోతే షెడ్యూల్ తప్ప మిగతావన్నీ మీరు రీస్టోర్ చేస్తారు.
• ఇన్‌స్టాల్ చేసిన ప్యాకేజీల జాబితా — dpkg --get-selections > /root/packages.txt. కిలోబైట్‌లు మాత్రమే తీసుకుంటుంది, గంటలు ఆదా చేస్తుంది.

మీరు బ్యాకప్ చేయాల్సిన అవసరం లేనివి

OS, ప్యాకేజీలు మరియు Docker ఇమేజ్‌లు మళ్లీ ఇన్‌స్టాల్ చేయడం మరియు కమాండ్‌లు రన్ చేయడం ద్వారా రీస్టోర్ అవుతాయి — అవి స్థలం మరియు సమయానికి విలువైనవి కావు. /proc, /sys, /dev, /var/lib/docker పూర్తిగా, క్యాష్ డైరెక్టరీలు లేదా స్వాప్ ఫైల్‌లను బ్యాకప్ చేయవద్దు.

సహేతుకమైన మార్గదర్శకం: ఇంటర్నెట్‌లో లేని మరియు సూచనల నుండి మీరు మళ్లీ సృష్టించలేని ప్రతిదీ బ్యాకప్‌లో ఉండాలి.

డేటాబేస్‌లు

రన్ అవుతున్న డేటాబేస్ యొక్క ఫైల్‌లను మీరు కాపీ చేయలేరు: రైట్ మధ్యలో తీసిన స్నాప్‌షాట్ మీకు లభిస్తుంది, అది తెరవకపోవచ్చు. సరైన మార్గం డేటాబేస్ యొక్క స్వంత టూల్స్ ఉపయోగించి డంప్ చేయడం.

docker compose exec -T db pg_dump -U postgres app | gzip > /backup/app-$(date +%F).sql.gz
docker compose exec -T db mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction app | gzip > /backup/app-$(date +%F).sql.gz
sqlite3 /data/app.db ".backup '/backup/app-$(date +%F).db'"

PostgreSQL మరియు MySQL కోసం మీరు సర్వీస్‌ను ఆపాల్సిన అవసరం లేదు. SQLite కోసం cp కాదు, .backup ఉపయోగించండి: అది రన్ అవుతున్నప్పుడు ఫైల్‌ను కాపీ చేయడం పాడైన డేటాబేస్‌ను ఉత్పత్తి చేస్తుంది.

మీరు ఎప్పుడూ రీస్టోర్ చేయని బ్యాకప్ బ్యాకప్‌గా పరిగణించబడదు. ఖాళీ మెషీన్‌లో లేదా ప్రత్యేక కంటైనర్‌లో దాన్ని పరీక్షించండి — రీస్టోర్ డ్రిల్ చూడండి.

పూర్తి సెట్ యొక్క ఉదాహరణ

#!/bin/bash
set -euo pipefail
DEST=/backup/$(date +%F)
mkdir -p "$DEST"

docker compose -f /opt/myapp/compose.yaml exec -T db pg_dump -U postgres app | gzip > "$DEST/db.sql.gz"
tar czf "$DEST/etc.tar.gz" /etc/nginx /etc/letsencrypt /opt/myapp/compose.yaml /opt/myapp/.env
tar czf "$DEST/uploads.tar.gz" /var/www/uploads
crontab -l > "$DEST/crontab.txt"
dpkg --get-selections > "$DEST/packages.txt"

స్క్రిప్ట్‌ను /usr/local/bin/backup.shలో ఉంచండి, దానికి chmod 700 అనుమతులు ఇవ్వండి మరియు దాన్ని షెడ్యూల్‌కు జోడించండి. తర్వాత మీరు బ్యాకప్‌ను మరొక లొకేషన్‌కు పంపాలి — మీ డేటా పక్కన ఉన్న ఫైల్ మిమ్మల్ని ఏది నుండి కూడా రక్షించదు.

ఎంతకాలం ఉంచాలి

సరళీకృత రూపంలో “3-2-1” నియమం: కనీసం రెండు కాపీలు, కనీసం ఒకటి ఈ మెషీన్ వెలుపల. రిటెన్షన్ కోసం, ఏడు రోజువారీ, నాలుగు వారంవారీ మరియు మూడు నెలవారీ సరిపోతాయి — మీరు వెంటనే గమనించని సైలెంట్ వైఫల్యానికి ముందు స్థితికి రోల్ బ్యాక్ చేయడానికి అది సరిపోతుంది.

మీ స్థలాన్ని ముందుగానే ప్లాన్ చేయండి: VDS-1లో 40 GB డిస్క్ ఉంది, మరియు దానిపై బ్యాకప్ హిస్టరీని నిల్వ చేయడానికి స్థలమే లేదు — డిస్క్ స్పేస్ చూడండి.

సాధారణ తప్పులు

• బ్యాకప్ అదే మెషీన్‌లో ఉంది. మళ్లీ ఇన్‌స్టాల్, యాక్సెస్ పోవడం, rm -rf తప్పు — మరియు బ్యాకప్ డేటాతో పాటు పోతుంది.
• మీరు .env మర్చిపోయారు. మీ దగ్గర డేటా ఉంది, కానీ దాని కోసం పాస్‌వర్డ్‌లు మరియు కీలు పోయాయి.
• అది రన్ అవుతున్నప్పుడు డేటాబేస్ వాల్యూమ్‌ను కాపీ చేయడం. పాడైన ఫైల్‌పై రీస్టోర్ విఫలమవుతుంది. డంప్‌లు మాత్రమే.
• బ్యాకప్ సృష్టించడం ఆగిపోయిందని ఎవరికీ తెలియదు. Uptime Kumaలో పుష్ చెక్ సెటప్ చేయండి: విజయవంతమైన తర్వాత స్క్రిప్ట్ ఒక అడ్రస్‌ను పింగ్ చేస్తుంది, మరియు ఒక రోజు నిశ్శబ్దం అలర్ట్‌ను ట్రిగ్గర్ చేస్తుంది.