Резервна копија и враќање на VPS датотеки
Резервната копија е корисна кога можете да ја преземете надвор од VPS и да ги вратите очекуваните датотеки. Оваа вежба архивира статична страница и една Nginx конфигурација, ги пренесува на друг компјутер и ги проверува вратените бајти без допирање на активен сајт.
VPSuntu · Ажурирано: · Читање: околу 5 мин
Содржина на водичот
Одредете го опсегот на вежбата
Користете Bash, GNU tar, sha256sum и OpenSSH на Ubuntu или Linux/WSL клиент. Серверските команди извршувајте ги во еден серверски терминал, клиентските во еден терминал на посебен компјутер. Оставете ги отворени за променливите да останат достапни. Запрете по секоја грешка.
Вежбата користи две привремени датотеки во home. Не менува Nginx, firewall или активна содржина, а распакувањето никогаш не се извршува како root. Почнете со примерните датотеки; опционалната замена ги користи само двете од водичот за статичен HTTPS сајт.
За поголем сајт направете одделен список на ресурси, redirects, вклучени конфигурации, 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"Командите ги читаат активните извори без да ги менуваат. Не копираат TLS приватни клучеви или цели системски директориуми. Дополнителни потребни датотеки додавајте намерно и во списокот и во checksum manifest.
Направете архива и две нивоа проверки
На серверот запишете checksums на избраните датотеки, создајте архива со релативни патеки и 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 ги проверува извлечените датотеки. Ниту еден не ја потврдува автентичноста ако некој може да ги замени и податоците и очекуваните checksums.
Копирајте на посебен компјутер
На клиентот поставете remote_backup на точниот export директориум испечатен од серверот. Заменете адреса, сметка и клуч со работните SSH податоци. 203.0.113.10 е документациска адреса; REPLACE е placeholder, не суфиксот создаден од 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/"Нов host fingerprint потврдете го преку доверлив канал. За проблем со SSH користете дијагностика на врската; не исклучувајте host-key проверка.
SCP го заштитува преносот преку SSH. Самата tar.gz архива е компресирана, не шифрирана. Заштитете ги сметката и дискот на одредиштето и применете шифрирање при складирање кога податоците го бараат. Друг директориум на истиот VPS не е независна копија.
Проверете и вратете во нов празен директориум
На клиентот проверете ја архивата пред распакување. Продолжете само ако 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 не ја враќа архивираната сопственост. Никогаш не поставувајте / како одредиште и не користете 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 и насловот од вратената страница. Ова ги проверува бајтите, не production сопственост, ACL, достапност на сервисот или сите зависности.
Одделете враќање датотеки од враќање сервис
Вратената конфигурација сè уште е неактивна текстуална датотека. На посебен заменски сервер проверете патеки, includes, модули, дозволи и сертификати. Валидирајте ја составената Nginx конфигурација таму пред reload, па проверете HTTP/HTTPS однадвор. Тест на непроменет активен сервер не ја валидира вратената копија.
Архивата намерно не содржи TLS приватни клучеви. Планирајте повторно издавање сертификат или одделно заштитена копија. Не архивирајте активни датотеки на база со оваа tar постапка: користете го поддржаниот конзистентен backup/restore на базата.
Snapshots помагаат при обновување машина, но проверете рок, failure domain и постапка. Постоечки snapshot не докажува дека извезените сајт-датотеки можат да се вратат на друг host.
Запишете цели и резултат од враќањето
RPO е прифатлива загуба на податоци изразена во време; RTO е целното време за враќање на сервисот. За мал статичен информативен сајт можни примерни цели се RPO 24 часа и RTO 60 минути. Ова не се измерени резултати. Дневен backup ја исполнува намерата само ако копиите успеваат и се обновливи.
На мал екран поместете ја табелата странично за да ги видите сите колони.
| Запис | Што покажува |
|---|---|
| Време на копија и издание | Која верзија може да се врати |
| Независно одредиште и рок | Каде преживува копијата и колку долго |
| Checksums на архива и датотеки | Дали избраните бајти се вратени |
| Почеток и крај на обновување | Време за дефинираните чекори |
| Недостасувачки датотеки, дозволи или зависности | Што останува пред враќање на сервисот |
| Надворешна HTTPS проверка на замената | Дали веб-страницата навистина работи |
Измерете го целиот процес пред да сметате дека RTO е остварлив: пристап, создавање машина, конфигурација, сертификати и DNS. Брзо локално распакување не е benchmark за реален прекин. Чувајте повеќе соодветни точки за враќање и следете неуспешни backup задачи. При избор користете ги критериумите за обновување кај хостингот.
Често поставувани прашања
Треба ли да го избришам оригиналниот сајт за тест?
Не. Враќање во посебен празен директориум со проверка на manifest ја тестира копијата без прекин. Целиот сервис испробајте го во заменска околина.
Дали успешен checksum значи целосен backup?
Ги потврдува датотеките во manifest. Не открива изоставена слика, база, тајна или DNS поставка. Водете список и испробајте ги вистинските функции по враќањето на сервисот.