# Знімки та резервні копії: виберіть збій, який потрібно пережити | SwissOctet Insights https://swissoctet.com/uk/insights/snapshots-backups-consistency/ SwissOctet / Аналітика / Зберігання та відновлення Зберігання та відновлення Прикладний · 4 хв читання Знімки та резервні копії: виберіть збій, який потрібно пережити Порівняйте точки відновлення, межі збоїв і узгодженість застосунку, а не припускайте, що знімок і незалежна резервна копія забезпечують однаковий захист. Автор: SwissOctet Editorial Зберегти посібник Копіювати посилання НА ЦІЙ СТОРІНЦІ 01 Опишіть копію, перш ніж називати її 02 Порівняйте збої, які ви очікуєте пережити 03 Перевірте узгодженість застосунку 04 Розглядайте збереження як вікно відновлення 05 Відокремте успішні завдання від перевірених даних 06 Перевірте невелике повне відновлення 07 Читайте додаткові резервні копії як окрему службу Ваш практичний контрольний список Джерела та додаткове читання Назад до бібліотеки ПРЯМА ВІДПОВІДЬ Знімок — це представлення на певний момент часу із захистом, визначеним його реалізацією. Стратегія резервного копіювання додає навмисне збереження, розділення доступу та перевірене відновлення. Деякі знімки є резервними копіями; інші залежать від оригінального сховища. Запитайте, що переживе видалення, компрометацію або втрату основного середовища. 01 Опишіть копію, перш ніж називати її Слово «знімок» говорить вам, що певний момент часу було представлено, але не про те, де зберігаються відновлювані дані чи хто може їх видалити. Знімок файлової системи на оригінальному сховищі та керований провайдером знімок блоку можуть мати різні межі збоїв. Почніть із реалізації, а не розглядайте мітку як універсальну обіцянку. AWS документує знімки EBS як інкрементальні резервні копії томів на певний момент часу. Це конкретна реалізація, а не доказ, що кожен варіант знімків поводиться однаково. Для будь-якої служби запитайте, чи залежить відновлення від оригінального тому, чи залишають копії основний домен збоїв і що станеться, коли джерело буде видалено. 02 Порівняйте збої, які ви очікуєте пережити Швидкий відкат після оновлення та відновлення після втрати облікового запису — різні проблеми. Локальний знімок може бути зручним для першої, пропонуючи мало розділення для другої. Незалежні копії можуть додати захист, але лише якщо їхні шляхи зберігання, доступу та видалення достатньо відокремлені від інциденту, до якого ви готуєтеся. Запишіть збій і потрібний результат. Це ілюстративне порівняння — допоміжний засіб для рішення, а не список функцій для SwissOctet. Воно заохочує запитання про копії та контроль, а не твердження, що одна технологія завжди краща. Фактичний результат залежить від конфігурації та задокументованого процесу відновлення оператора. Сценарій Питання для знімка Питання для резервної копії Погане оновлення застосунку Чи можу я повернутися до потрібного моменту? Скільки часу займає придатне відновлення? Втрачено основний диск Чи залежить копія від цього диска? Чи можу я відновити на нове сховище? Скомпрометовано адміністративний обліковий запис Чи може цей обліковий запис видалити кожну копію? Чи розділені права на видалення? Помилку виявлено через тижні Чи збережено ще той момент? Чи покриває збереження затримку виявлення? 03 Перевірте узгодженість застосунку Диск може зафіксувати файли, поки застосунок ще змінює їх. Залежно від програмного забезпечення та процесу знімка результат може представляти стан, узгоджений із аварійним завершенням, а не скоординований стан застосунку. Не припускайте, що читабельні файли означають узгодженість бази даних і пов'язаних із нею завантажень. Використовуйте метод резервного копіювання, задокументований застосунком або базою даних. Дизайн безперервного архівування PostgreSQL ілюструє різницю: відновлення потребує відповідної базової резервної копії та безперервної послідовності потрібних файлів журналу попереднього запису. Каталог, скопійований недбало під час роботи бази даних, не є еквівалентною процедурою. Якщо застосунок також зберігає файли поза базою даних, сплануйте, як ці два набори даних відновлюються разом. 04 Розглядайте збереження як вікно відновлення Збереження має враховувати, як довго помилка може залишатися непоміченою. Десятиденне вікно не допоможе при випадковому видаленні, виявленому через місяць. Збереження кожної копії безстроково створює іншу проблему: витрати, зростання впливу чутливих даних і нечітка політика видалення. Вибирайте збереження з конкретних операційних вимог і вимог до обробки даних. Позначайте точки відновлення корисним контекстом, як-от версія застосунку та час завершення завдання, не вбудовуючи секрети. Зберігайте достатньо історії, щоб відрізнити добрий стан від пошкодженого. Перед очищенням підтвердьте, як вибрана система обробляє спільні або інкрементальні дані; видалення позначеної точки може не відповідати видаленню простого окремого файлу. 05 Відокремте успішні завдання від перевірених даних Повідомлення інструмента резервного копіювання про успіх засвідчує, що його процес завершився за його правилами. Це не доводить автоматично, що всі важливі дані застосунку було вибрано, кожен збережений байт залишається цілим або новий сервер може використати результат. Це різні перевірки. Включіть стан репозиторію, перегляд вибору та репрезентативне відновлення в операційний план. Restic документує різницю між перевіркою репозиторію за замовчуванням і перевіркою, яка читає збережені дані пакетів. Повна перевірка з читанням даних може споживати більше часу та пропускної здатності. Цей приклад робить планувальний момент конкретним: вирішіть, що саме читає перевірка, і розподіліть бюджет роботи. Використовуйте документацію інструмента, а не припускайте, що кожна команда з назвою check має однакове покриття. 06 Перевірте невелике повне відновлення Уявіть видання з базою даних, завантаженими зображеннями та конфігурацією. Відновіть усі три в приватному тестовому середовищі, потім відкрийте статтю та перевірте її вкладення. Тримайте заплановані інтеграції пошти, платежів і публікації вимкненими під час вправи. Перевірка лише випадкового текстового файлу пропустила б зв'язки, які роблять застосунок корисним. Виміряйте потрібний час і запишіть, яких облікових даних, версій пакетів або зовнішніх залежностей бракувало. Перегляньте дозволи на відновлених файлах, а не лише їхній вміст. Вправа з відновлення часто виявляє, що дані існують, але інструкції чи доступ, потрібні для їх використання, ніколи не зберігалися разом з операційним планом. 07 Читайте додаткові резервні копії як окрему службу Налаштовуючи SwissOctet, перегляньте точний варіант резервного копіювання та період збереження для сімейства. Запитайте, які томи та дані застосунку він охоплює, чи є відновлення самообслуговуванням і що станеться, коли основна конфігурація зміниться. Сама мітка опції не встановлює незалежну копію, незмінний репозиторій або точку відновлення, узгоджену з базою даних. Використовуйте знімки там, де вони відповідають навантаженню, і тримайте ширшу стратегію резервного копіювання для збоїв, які вони не покривають. Запишіть незалежний шлях відновлення для важливих даних, захистіть облікові дані, які можуть стерти копії, і перевірте процедуру. Найсильніший вибір — той, що переживає ваш визначений сценарій, а не той із найбільш заспокійливою назвою. ПЕРЕТВОРІТЬ ЦЕ НА ДІЮ Ваш практичний контрольний список. ✓ Визначте, де зберігаються відновлювані дані. ✓ Перелічіть збої, які має пережити копія. ✓ Використовуйте метод узгодженості, підтримуваний застосунком. ✓ Виберіть збереження для вікна виявлення. ✓ Захистіть права на видалення окремо. ✓ Відновіть повний застосунок в ізоляції. Завантажити контрольний список ПОШИРЕНІ ЗАПИТАННЯ Деталі, які мають значення. Чи знімок ніколи не є резервною копією? + Деякі реалізації знімків є резервними копіями. Корисна відмінність — їхня залежність від сховища, збереження, модель доступу та перевірене відновлення, а не сама мітка. Чи доводить успішна перевірка цілісності, що застосунок працюватиме? + Вона доводить лише те, що охоплює ця перевірка. Перевірте відновлення застосунку, конфігурацію, дозволи та зв'язки даних окремо. Чи слід зберігати резервну копію на тому самому сервері? + Копія на тому самому сервері може допомогти з обмеженими помилками, але поділяє важливі збої. Важливі дані потребують шляху відновлення поза межею збою, яку ви маєте намір пережити. ОСНОВНІ ДЖЕРЕЛА Перейдіть до джерела. Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи. Amazon EBS: Знімки docs.aws.amazon.com PostgreSQL: Безперервне архівування та відновлення на певний момент часу www.postgresql.org Restic: Робота з репозиторіями та перевірками цілісності restic.readthedocs.io Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо. ПОЄДНАЙТЕ ЗНАННЯ Пов'язана інфраструктура. Vault Storage Швейцарія Pulse NVMe Швейцарія Metal Zenith Швейцарія ЗБЕРІГАЙТЕ НИТКУ Ваші наступні польові нотатки. Дослідити всі посібники ПОЛЬОВА НОТАТКА / 01 + Зберігання та відновлення Основа Коли NVMe має значення для вашого застосунку Розрізняйте потужність, затримку та пропускну здатність, щоб швидший ярлик сховища відповідав реальній проблемі застосунку. 4 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 02 + Зберігання та відновлення Просунутий Вимірюйте продуктивність NVMe, не вводячи себе в оману Визначте шаблон введення/виведення, контролюйте ефекти кешу та дослідіть розподіли затримки, перш ніж робити висновок про застосунок із тесту диска. 6 хв читання Читати посібник ПОЛЬОВА НОТАТКА / 03 + Зберігання та відновлення Основа Об'єктне, файлове або блокове зберігання: виберіть інтерфейс, потрібний вашому застосунку Розрізняйте інтерфейси зберігання, семантику доступу та операційні обов'язки, перш ніж перетворювати вимогу до ємності на архітектуру застосунку. 4 хв читання Читати посібник