Резервна копія — це запитання. Відновлення відповідає на нього.

Тримайте перше навчання навмисно малим

Ця вправа створює іграшкову базу даних нотаток і одне вкладення, захоплює обидва, а потім відновлює їх у нову базу даних і каталог. Використовуйте одноразову машину Linux з сервером PostgreSQL 17 та відповідними клієнтськими утилітами, Bash і GNU coreutils. Вона не повинна містити виробничих даних і не мати зв'язку з виробничими застосунками, вихідною поштою або запланованими завданнями. Використовуйте лише архів, створений у цій вправі.

Команди припускають попередньо налаштовану роль бази даних без прав суперкористувача з іменем restore_lab, якій дозволено створювати тестові бази даних, і OS-логін з тим самим іменем, який може автентифікуватися локально. Сокет PostgreSQL — /var/run/postgresql на порту 5432. Нехай адміністратор підготує цей обліковий запис у одноразовому середовищі; цей посібник не змінює правила доступу до бази даних. Перевірте кінцеву точку перед створенням чого-небудь:

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Зупиніться, якщо хост, обліковий запис або версія неочікувані. Тримайте клієнти та сервер на одній мажорній версії для цього першого навчання. pg_dump не може зробити дамп сервера, новішого за власну мажорну версію, і старіша ціль відновлення зазвичай не гарантовано сумісна. Дивіться обмеження версії pg_dump. Запускайте кожен блок окремо і зупиняйтеся на помилці. && запобіжники не дають наступним командам у вставленому блоці виконуватися після збою; ніколи не переходьте до наступного блоку після невдалого створення бази даних або каталогу.

Створіть запис і відповідний йому файл

Імена offvps_restore_source та offvps_restore_target повинні бути невикористаними. Наявна база даних — це причина зупинитися і вибрати нову ізольовану вправу, а не причина видалити її. Створіть свіжий робочий простір файлової системи та вихідну базу даних:

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

Свіжий робочий простір уникає перезапису наявного каталогу. mktemp створює унікальний каталог; createdb створює нову базу даних із вибраного шаблону. Збережіть ці два маркери:

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

Запис указує, який файл належить нотатці, і обидва містять той самий маркер. Це робить видимим відсутнє вкладення або невідповідну копію. -X уникає персональних налаштувань запуску psql і ON_ERROR_STOP зупиняється на помилці SQL; дивіться параметри скриптування psql. Немає застосунку, що пише в цей іграшковий набір даних.

Захопіть базу даних і файли як один набір відновлення

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

Архів у спеціальному форматі читається pg_restore; звичайний SQL-дамп використовує іншу процедуру відновлення. Перелік архіву допомагає підтвердити наявність очікуваної таблиці та записів даних. Узгоджений дамп бази даних не синхронізує автоматично зовнішні завантаження. Для реального застосунку використовуйте його документовану процедуру обслуговування або паузи запису, щоб дерево файлів і база даних описували один момент часу. Іграшкова вправа вже тиха.

Запишіть версію бази даних, реліз застосунку, початок/кінець захоплення та шлях до файлів поряд із пакетом. Тримайте справжні облікові дані окремо під відповідним контролем доступу. Дамп окремої бази даних не захоплює глобальні ролі та табличні простори; реальний план відновлення повинен враховувати і їх. Обсяг описано в посібнику з SQL-дампів PostgreSQL.

Відновіть у нові цілі, не очищаючи наявну

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

Цільова база даних створюється порожньою. Відновлення навмисно пропускає --clean, що могло б видалити наявні об'єкти. --single-transaction змушує відновлення цієї маленької бази даних або успішно завершитися як одне ціле, або зупинитися без застосування часткових змін; його не можна поєднувати з паралельними завданнями. --no-owner та --no-acl спрощує володіння для цієї тестової ролі, тож це навчання не перевіряє виробничі ролі чи дозволи застосунку. Дивіться pg_restore.

Копіювання файлів спрямоване в новий каталог відновлення, залишаючи джерело недоторканим. GNU cp -a намагається зберегти атрибути файлів; перевірте власність і доступ для облікового запису, який запускатиме реальний застосунок. Копіювання байтів не є перевіркою дозволів застосунку. Дивіться параметр архіву cp.

Перевіряйте зв'язок, а не лише коди виходу

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Очікувані результати — один рядок з ID 1, тіло restore-marker-01 і вкладення marker.txt, плюс файл, що містить restore-marker-01. Перевірте, що джерело все ще містить початковий рядок і файл. Для вашого реального застосунку також спрямуйте ізольований екземпляр на відновлену базу даних і каталог завантажень, відкрийте репрезентативні записи, отримайте вкладення та перевірте призначені дозволи входу. Під час цього тримайте зворотні виклики, пошту та завдання обмеженими.

Запишіть, що ви довели і що залишилося

Очікувані результати вище — це критерії вправи, а не результати, вже спостережені OffVPS. Оскільки перше навчання тримає всі файли на одній машині, воно не забезпечує захисту від втрати цієї машини. Реальний план потребує захищеної копії в окремому домені відмови, придатних ключів розшифрування, збереження та перевіреного шляху отримання. Перегляньте точні назви одноразових баз даних і каталог перед подальшим очищенням; тримайте виробництво поза цим процесом.

Повторюйте вправу після важливих змін і фіксуйте невдачі так само ретельно, як успіхи. Необов'язковий сервіс резервного копіювання не доводить час відновлення вашого застосунку. Продовжте з планування запланованого завдання коли будете готові автоматизувати захоплення, зберігаючи окреме навчання з відновлення.