Модул 8 · 8.1

План за резервни копия на Вашия сървър

Модул 8: Резервни копия и наблюдение · Време за четене: 11 минути

Цел на урока: След този урок ще можете да съставите план за резервни копия на собствения си сървър: какво пазите, къде, колко често и колко дълго, и как да сте сигурни, че възстановяването работи.

Основни понятия: правило 3-2-1, snapshot, резервно копие от доставчика, собствено резервно копие извън доставчика, RPO, RTO, dump на базата данни (mariadb-dump, pg_dump), конфигурация в /etc, Docker volumes, криптиране, ransomware, append-only, тест за възстановяване

Защо е нужен план, а не просто "нали има резервно копие"?

Почти всеки, който е загубил сървър, е смятал, че има резервно копие. После се оказва, че то съдържа само операционната система, но не и базата данни, или че се намира на същия сървър, който вече го няма, или че е криптирано от същия ransomware, или че никой не знае паролата. Резервното копие има стойност едва когато можете да го възстановите. Затова започвате с план и завършвате с тест.

Планът отговаря на пет въпроса:

Какво трябва да може да се възстанови?
Колко данни можете да си позволите да загубите? (RPO)
Колко бързо всичко трябва да заработи отново? (RTO)
Къде се намират копията и колко са те?
Как разбирате, че всичко работи?

Какво трябва да може да се възстанови?

Сървърът се състои от слоеве. Не всеки слой трябва да влиза в резервното копие:

Слой	Пример	Резервно копие?
Операционна система и пакети	Debian, nginx, PHP	Не непременно: могат да се инсталират отново. Но пазете списък: `dpkg --get-selections`
Конфигурация	`/etc` (nginx, SSH, защитна стена, systemd units), Вашите compose файлове	Да, малка по обем и незаменима
Приложения и уебсайтове	`/var/www`, `/opt/<app>`, `/srv`	Да, освен ако идват от Git
Данни	бази данни, качени файлове, Docker volumes (`/var/lib/docker/volumes`)	Да, това е най-важното
Тайни	пароли, API ключове, ключът на самото резервно копие	Да, но отделно и криптирано (вижте по-долу)
Логове, кешове, временни файлове	`/var/log`, `/var/cache`, `/tmp`	Обикновено не

Обърнете специално внимание на базите данни. Работещата база данни записва непрекъснато. Ако копирате файловете на работеща MariaDB или PostgreSQL, може да получите повредено копие. Затова първо направете dump: консистентна моментна снимка във вид на файл, която след това включвате в резервното копие.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump по-рано се казваше mysqldump; тази команда обикновено все още работи.) Ако базата данни работи в контейнер, правите същото с docker compose exec (урок 9.4).

RPO и RTO: колко можете да загубите?

Две понятия от професионалната практика помагат при избора:

RPO (recovery point objective): данни за какъв период най-много можете да загубите? Ежедневно резервно копие в 03:00 означава: ако сървърът се срине в 22:00, губите почти цял ден. За онлайн магазин с поръчки това е твърде много; за блог, който се променя веднъж седмично, е напълно достатъчно.
RTO (recovery time objective): колко време може да мине, докато всичко заработи отново? Възстановяването на пълно резервно копие от доставчика може да отнеме минути; изграждането на нов сървър и ръчното възстановяване на всичко може да отнеме часове.

Запишете ги за собствения си сървър. Те определят колко често правите резервно копие и как го съхранявате.

Snapshot, резервно копие от доставчика, собствено резервно копие

При VPS обикновено разполагате с три вида предпазна мрежа. Те си приличат, но защитават от различни неща.

1. Snapshot. Моментна снимка на целия виртуален диск, направена в панела на Вашия доставчик. Създава се бързо и се възстановява бързо. Идеален точно преди надграждане (урок 4.3). Но: при повечето доставчици snapshot се пази на същото хранилище като сървъра Ви. Ако това хранилище се повреди или загубите акаунта си, snapshot също изчезва. И snapshot не се пази дълго: той нараства с всички промени след създаването му. Snapshot не е резервно копие.

2. Резервното копие от доставчика. Много доставчици (понякога като допълнителна опция) автоматично правят всеки ден копие на целия Ви сървър на друго хранилище. При WebOké например това е ежедневно резервно копие на целия VPS, което се пази седем дни; при други доставчици работи по подобен начин, със собствени срокове. Това е добър втори слой срещу повреден хардуер и срещу Вашите собствени грешки от вчера. Но остава една и съща страна: Вашият акаунт, Вашето плащане, тяхната авария. А възстановяването обикновено става за целия сървър наведнъж.

3. Вашето собствено резервно копие, извън доставчика. Копие на Вашите данни при друга страна или на друго място, което Вие създавате и управлявате (урок 8.2). Това е слоят, който остава, когато всичко друго се провали.

Правилото 3-2-1

Утвърдено практическо правило:

3 копия на Вашите данни (оригиналът плюс две резервни копия);
на 2 различни вида хранилища или системи;
от които 1 на друго местоположение.

За VPS това може да бъде: данните на сървъра, ежедневното резервно копие от доставчика и криптирано собствено резервно копие с restic в хранилище при друга страна. Съвременно допълнение е поне едно копие да не може да бъде изтрито от този, който поеме контрола над сървъра (offline или append-only, урок 8.2). Ransomware на сървър активно търси резервни копия, за да ги криптира или изтрие и тях. Резервно копие, което самият сървър може да изтрие, не дава защита срещу това.

Криптиране и паролата на Вашето резервно копие

Резервното копие при друга страна трябва да е криптирано: в него има данни на клиенти, пароли и ключове. restic (урок 8.2) криптира по подразбиране. Но така възниква нов риск: паролата на Вашето резервно копие. Ако я загубите, резервното копие е неизползваемо. Същото важи, ако тя се намира само на сървъра, който сте загубили.

Затова пазете паролата и извън сървъра: в мениджъра си за пароли и евентуално на хартия в сейф. Същото се отнася и за данните за достъп до хранилището, в което се намира резервното Ви копие.

Тестване на възстановяването

Най-важната част от плана. Тест за възстановяване означава: наистина възстановявате резервно копие на място, където нищо няма да повредите, и проверявате дали резултатът работи.

Малко и често: възстановете един файл или една папка в /tmp/terug и сравнете (diff). Например ежемесечно.
Голямо и от време на време: изградете изцяло нов тестов сървър от резервното копие, импортирайте базата данни, стартирайте уебсайта. Например веднъж годишно или при всяка голяма промяна. Това е и упражнение за момента, в който нещата наистина се объркат (урок 10.3).

Запишете колко време е отнело: това е Вашето реално RTO.

Срокове за съхранение

Не пазете само последното резервно копие. Ако едва след две седмици откриете, че файл е повреден или изтрит, ще Ви трябва резервно копие отпреди три седмици. Утвърдена схема: седем ежедневни, четири седмични и шест месечни версии. restic урежда това с forget (урок 8.2). Помислете и за GDPR (ОРЗД): личните данни не се пазят по-дълго от необходимото, включително в резервните копия. Документирайте сроковете си за съхранение.

На практика

Използвайте snapshot на доставчика точно преди рискови промени и след това го изтрийте; оставете ежедневното резервно копие от доставчика включено, ако има такова; и освен това правете собствено криптирано резервно копие на данните и конфигурацията при друга страна. При WebOké това се нарича Snapshots и Backups в екрана на VPS; при други доставчици имената и сроковете са различни, но принципът е същият. При хостинг пакет или управлявана услуга често важат други условия: проверете какво е уредено във Вашия случай.

Обобщение

Резервното копие има стойност едва когато възстановяването работи; започнете с план и завършете с тест.
Правете резервни копия преди всичко на данните и конфигурацията: бази данни като dump, /etc, уебсайтове, Docker volumes, compose файлове.
Определете RPO (колко можете да загубите) и RTO (колко бързо трябва да заработи).
Snapshot (същото хранилище, за кратко), резервно копие от доставчика (друго хранилище, същата страна) и собствено резервно копие извън доставчика са три различни слоя; следвайте правилото 3-2-1 с поне едно копие, което самият сървър не може да изтрие.
Криптирайте, пазете паролата на резервното копие извън сървъра и тествайте възстановяването: малко и често, голямо от време на време.

Тест (quiz)

Задача

Задача O8.1: Вашият план за резервни копия. Съставете за собствения си сървър план за резервни копия на една страница: какво трябва да може да се възстанови (по слоеве), Вашите RPO и RTO, какви копия имате (snapshot, от доставчика, собствено) и къде, сроковете Ви за съхранение, къде се пази паролата на резервното копие и кога правите тест за възстановяване. Попълнете формуляра; след изпращането ще видите примерен план, с който да сравните своя.

Задача O8.1: Вашият план за резервни копия

Тази задача изпълнявате сами; никой не я проверява. Отбележете какво сте направили и маркирайте задачата като изпълнена.

За всеки слой е определено какво пазя: конфигурация, сайтове, бази данни, volumes, тайни
RPO и RTO са определени
Копие при друг доставчик, различен от този на сървъра
Сроковете за съхранение са избрани
Знам къде се намира паролата за резервните копия
Има копие, което самият сървър не може да изтрие

Как съхранявате базите си данни?

Къде се намират копията Ви и при кой доставчик?

Кога и как тествате възстановяването?

Вашите отметки и бележки остават само в този браузър; не ги изпращаме никъде. Ако сте влезли, в Моите курсове запазваме само че сте изпълнили задачата.

Бисквитки в WebOké

Настройки за бисквитки

Необходими

Маркетинг