Оператор у Панамі · Без KYC · Monero6 місяців −28% Рік −50% · сплачено наперед

Операції та відновлення

Відрепетируйте вихід, перш ніж залежати від нього.

Переносимість слід перевіряти тренуванням відновлення. Інвентаризуйте повний застосунок, підготуйте відновлювану копію, незалежну від джерела, і відновіть на ізольованій цілі, перш ніж планувати переміщення. Лише експортована база даних не доводить, що сервіс може працювати в іншому місці.

Переглянуто · Ресурси Hosmio

Перш ніж почати

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

01

Перелічіть, що потрібно перемістити, а що відтворити.

Включіть середовище виконання, базу даних, завантажені файли, конфігурацію, заплановані задачі, сертифікати, володіння DNS і зовнішні інтеграції. Запишіть, хто контролює кожну залежність і як можна відновити доступ, якщо поточний VPS недоступний. Визначте будь-яку функцію, специфічну для постачальника, яка потребує заміни, а не копіювання файлів.

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

02

Виберіть метод експорту та відновлення з урахуванням даних.

Для PostgreSQL логічний експорт за допомогою pg_dump охоплює одну базу даних, тоді як глобальні об’єкти, як-от ролі, потребують окремого опрацювання. Інструмент відмовляється вивантажувати сервер з новішої мажорної версії, ніж підтримує клієнт. Офіційна документація також застерігає від того, щоб вважати pg_dump універсальною стратегією регулярного резервного копіювання для продакшену. PostgreSQL: pg_dump ↗

Виберіть метод, доцільний для вашого застосунку та потреб відновлення, разом з його оператором. Зафіксуйте, що саме експорт не включає та як файли підтримуються узгодженими з посиланнями бази даних. Успішне завершення команди — це корисна перша перевірка, а не доказ того, що збережено повний застосунок.

03

Відновіть у явно окрему ціль.

Перегляньте архів і призначення перед відновленням. Для відновлення архівів PostgreSQL використовується pg_restore; параметри, які очищають наявні об’єкти, можуть видалити дані, а його типова поведінка може продовжуватися після помилок SQL. Сплануйте обробку помилок і перегляньте результат, а не припускайте, що всі об’єкти відновлено. PostgreSQL: pg_restore ↗ Не виконуйте навчальний посібник на продакшен-базі даних лише тому, що її назва знайома.

Для файлових резервних копій виберіть потрібний знімок і порожнє тестове призначення. Restic документує, що відновлення може перезаписати наявні файли; перервана перезапис може залишити частковий результат. restic: відновлення з резервної копії ↗ Запишіть вихідний знімок і цільовий шлях у нотатці про вправу. Це методичні рекомендації щодо вибору, а не команди, виконані чи перевірені на VPS Hosmio.

04

Перевірте задачі користувачів і приховані побічні ефекти.

Ілюстративний аркуш приймання вихідного тренування
ПеревіркаДокази для збереженняРезультат
Застосунок запускається з задокументованими версіямиІнвентаризація версій і результат запускуЩе не тестовано
Репрезентативні записи та файли збігаютьсяПеревірки синтетичних записів і вкладеньЩе не тестовано
Дозволи поводяться правильноДві тестові ролі й очікуваний доступЩе не тестовано
Завдання не надсилають дубльовану зовнішню роботуВихідні дії вимкнено або контрольований тестЩе не тестовано
Оператор заміни може діяти за нотаткамиНезалежний прохід і прогалиниЩе не тестовано

Використовуйте синтетичні облікові записи та нешкідливі тестові записи, де це можливо. Перевіряйте межі доступу так само, як і успішне читання. Застосунок, який запускається, але надає неправильні дозволи, не є успішним відновленням. Зберігайте невдалі перевірки в записі з відповідальним за виправлення.

05

Сплануйте момент, коли нові записи змінять рішення.

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

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

06

Залиште докази, які може використати інший оператор.

Запишіть дату вправи, версії, ідентифікатори копій, ціль, витрачені зусилля та результати лише після того, як вправу фактично виконано. До того часу використовуйте «заплановано» або «не тестовано». Зберігайте аркуш приймання разом із нотатками про відновлення та перелічіть залежності, які все ще перешкоджають незалежній перебудові.

Якщо репетиція не вдалася, класифікуйте прогалину: відсутні дані, несумісне програмне забезпечення, недоступні облікові дані, зовнішня залежність або незрозуміла процедура. Вирішіть найменшу блокуючу проблему, потім повторіть відповідну перевірку. Не називайте застосунок переносним, поки критичне завдання залишається неперевіреним.

Пов’яжіть план із визначеними операційними обов’язками та процесом затвердження змін клієнта. Бажаний результат — продемонстрована здатність відновитися в задокументованому обсязі, а не обіцянка нульового переривання чи автоматично виконаної міграції.