# Снимки и резервные копии: выберите сбой, который вам нужно пережить | SwissOctet Insights https://swissoctet.com/ru/insights/snapshots-backups-consistency/ SwissOctet / Аналитика / Хранение и восстановление Хранение и восстановление Прикладное · 4 мин чтения Снимки и резервные копии: выберите сбой, который нужно пережить Сравните точки восстановления, границы сбоев и согласованность приложений, вместо того чтобы предполагать, что снимок и независимая резервная копия обеспечивают одинаковую защиту. От редакции SwissOctet Сохранить руководство Скопировать ссылку НА ЭТОЙ СТРАНИЦЕ 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 мин чтения Читать руководство