Размер хранилища S3 и правило backup 3-2-1

Размер хранилища S3 определяется тремя числами: сколько данных вы защищаете, сколько прошлых версий храните и насколько хорошо ваш инструмент backup избегает хранения одних и тех же байтов дважды. Сайт на 5 GB, хранящийся в виде четырнадцати ежедневных полных копий, требует 70 GB; та же история в инструменте с дедупликацией вроде restic часто укладывается в 10-15 GB. Затем решите, какое место бакет занимает в правиле 3-2-1: три копии данных, на двух разных типах хранилищ, одна из них где-то в другом месте. Бакет с одной копией в одной площадке - хорошая вторая или третья копия и плохая единственная, а реплицированное хранилище тоже не равно backup: репликация добросовестно копирует ваши ошибки. В этой статье оба вопроса разобраны на реальных числах, чтобы вы купили подходящий тариф и точно знали, от чего он защищает, а от чего нет.

Правило 3-2-1 и зачем каждое число#

Правило старше облачных хранилищ и выжило потому, что каждое число отвечает на свой тип сбоя.

Распространённое современное расширение - 3-2-1-1-0: одна копия офлайн или неизменяемая, чтобы никто с вашими учётными данными не мог её удалить, и ноль ошибок при проверке восстановления. Последнюю цифру люди пропускают, а она важнее всех. Подробно это обосновано в статье backup, которые действительно восстанавливаются.

Что считать «другим типом хранилища», сегодня понимается свободнее, чем когда правило означало ленту против диска. Суть - в независимости: backup панели и бакет S3 в другом сервисе - разные системы с разными учётными данными и разными способами сломаться, и именно к этому стремится «2». Две папки на одном сервере - не два типа хранилища. Два бакета под одним ключом доступа - едва ли две копии.

Одна копия, репликация и от чего защищает каждая#

Провайдеры хранилищ описывают надёжность по-разному, и стоит точно понимать, что именно обещано.

Реплицированное хранилище держит несколько копий каждого объекта на разных дисках, машинах или площадках. Крупные провайдеры называют показатели надёжности со множеством девяток, и это значит: вероятность того, что оборудование потеряет сохранённый вами объект, крайне мала. Это реальное и ценное свойство.

Хранилище с одной копией хранит ваш объект один раз. В большинстве схем он всё равно лежит на избыточных дисках, но держит его одна система в одном месте.

Теперь посмотрите, что на практике уничтожает backup:

Две верхние строки - это то, для чего нужна репликация. Четыре нижние - то, что в большинстве разборов инцидентов и произошло на самом деле. Репликация защищает от того, что вас подведёт оборудование провайдера; от того, что вас подведёте вы сами, ваши скрипты или ваши учётные данные, она не защищает никак. Поэтому бакет с одной копией может быть вполне хорошей частью плана backup, а реплицированный бакет сам по себе планом backup не является.

Хранилище S3 у RE:NODE - с одной копией, и об этом прямо сказано: одна копия ваших данных на NVMe в одной площадке в Германии, без репликации. У тарифов хранилища к тому же нет слотов backup в панели - бакет и есть backup, а не то, что само копируется. Это делает его хорошим местом для второй копии ваших backup и для загрузок приложения, которые существуют где-то ещё. Но он не должен быть единственным местом, где что-то хранится.

Что стоит хранить в объектном хранилище#

Объектное хранилище хорошо подходит для файлов, которые записываются один раз и читаются много раз по HTTP откуда угодно. И плохо - для файлов, которые меняются понемногу.

Хорошо подходит:

• Копии backup - репозитории restic, дампы баз данных, архивы игровых миров, снимки серверов, экспортированные в файлы.
• Пользовательские загрузки и медиа - аватары, вложения, фото товаров, сгенерированные PDF, если приложение или задание backup держит их ещё где-то.
• Артефакты сборок и релизов - версионированные файлы, которые нужно забирать на несколько серверов.
• Архивы логов - сжатые ежедневные логи, унесённые с сервера, который их записал.
• Выгрузки данных и передача файлов - файлы, которыми вы делитесь через presigned-ссылку вместо вложения в письмо.

Плохо подходит:

• Рабочая база данных. Базы постоянно перезаписывают мелкие блоки, а S3 заменяет объекты целиком. Храните дампы, а не каталоги данных.
• Подключённый «диск» для приложения, которое много пишет. Работает, но медленно, с большим трафиком и странной согласованностью.
• Единственная копия чего бы то ни было. Это правило относится к любой системе хранения, но для системы с одной копией его стоит повторить.

Сколько места: арифметика#

Размер определяют три входных значения:

1. Размер источника - то, что вы защищаете, после сжатия. Базы данных сжимаются хорошо (часто в 5-10 раз для дампов с большим количеством текста); картинки, видео и игровые миры - почти никак.
2. Срок хранения - сколько точек восстановления вы держите.
3. Скорость изменений и дедупликация - какая доля каждой точки восстановления - новые данные и сохраняет ли инструмент неизменённые данные повторно.

Последняя строка - замаскированная ловушка: синхронизация без истории - это зеркало, а зеркало - копия всего, что пошло не так. Не считайте её backup.

Добавьте к результату запас. Неожиданно место съедают две вещи: брошенные multipart-загрузки (большая загрузка, убитая на полпути, оставляет свои части, пока кто-нибудь их не отменит) и рост самого источника. Разумное правило - покупать примерно в 1,5 раза больше, чем говорит арифметика, и раз в месяц смотреть на фактическое использование.

Срок хранения: как далеко назад нужно уходить#

Срок хранения - множитель в любом расчёте размера, поэтому он заслуживает решения, а не значения по умолчанию. Вопрос не в том, «сколько backup ощущается безопасным», а в том, «как долго проблема может оставаться незамеченной».

Некоторые проблемы заявляют о себе сами: сервер не запускается, сайт показывает ошибку, игроки жалуются в течение часа. Их покрывают ежедневные копии за день-два. Другие ведут себя тихо. Плагин, который портит одну таблицу, задание cron, которое удаляло не ту папку, грифер, спрятавший разрушения в углу карты, куда никто не заходит, злоумышленник, изменивший файл и затаившийся. Такое находят через дни или недели, и помогает только backup, сделанный до начала проблемы. Если вашей самой старой точке восстановления семь дней, а повреждению - десять, оно есть в каждом вашем backup.

Поэтому обычный ответ - многоуровневое хранение по схеме «дед-отец-сын». Держите много свежих точек близко друг к другу и меньше старых - с большими промежутками:

Двадцать с небольшим точек восстановления охватывают год, а с инструментом дедупликации старые точки стоят очень мало, потому что большая часть их данных общая с новыми. С полными копиями место уходит именно на ежемесячный уровень, так что посчитайте его стоимость, прежде чем обещать себе год истории.

Примеры расчёта#

Сервер Minecraft с миром на 3 GB. Миры почти не сжимаются. Четырнадцать полных копий по датам заняли бы 42 GB; restic, при котором большинство файлов регионов от ночи к ночи не меняется, обычно хранит первую копию плюс несколько сотен мегабайт в день - скажем, 6-9 GB для двух недель ежедневных копий и нескольких ежемесячных. С restic хватит тарифа на 10 GB; для полных копий по датам - тарифа на 50 GB. Само задание собирается в статье backup игрового сервера в S3.

Веб-приложение с базой PostgreSQL на 2 GB и 20 GB загрузок. Дамп в custom-формате сжимается, скажем, до 400 MB. Хранение 7 ежедневных, 5 еженедельных и 12 ежемесячных дампов - это 24 файла, около 10 GB. Загрузки, синхронизируемые с историей через restic, - это 20 GB плюс их рост. Вместе сегодня около 35 GB, так что подойдёт тариф на 50 GB с запасом на рост. Скрипт для срока хранения есть в статье дампы баз данных в S3 по расписанию.

Небольшой офис с 60 GB общих документов. Офисные файлы сжимаются умеренно и меняются медленно. restic с 30 ежедневными и 12 ежемесячными точками может потребовать 75-90 GB. Это тариф на 100 GB - а для бизнеса третья копия дома или у второго провайдера не обсуждается.

Тарифы хранилища RE:NODE идут от 10 GB до 100 GB, от $1.5 в месяц. Переход на тариф выше меняет лимит на уже существующем сервере, а не пересобирает его, так что начать с малого и расти - разумная стратегия, если следить за использованием до того, как упрётесь в потолок, а не после.

Проверка фактического использования#

Измеряйте бакет, а не свою оценку. Общий объём дают две команды:

$ aws s3 ls s3://backups --recursive --summarize --human-readable --profile store | tail -n 2$ rclone size store:backups

Обе перечисляют каждый объект, поэтому на бакете с миллионами ключей они работают долго; для обычных бакетов с backup они заканчивают за секунды. Поищите также забытые multipart-загрузки, которые не видны в обычном листинге, но занимают место:

$ aws s3api list-multipart-uploads --bucket backups --profile store$ aws s3api abort-multipart-upload --bucket backups --key big.tar --upload-id <id> --profile store

Для репозиториев restic restic stats --mode raw-data показывает, сколько места репозиторий реально занимает после дедупликации, - именно это число нужно сравнивать с тарифом. А если объём растёт быстрее ваших данных, обычная причина - задание срока хранения, которое перестало запускаться: проверьте, что forget --prune или ваш скрипт удаления всё ещё выполняется.

Схема 3-2-1 с бакетом на одну копию#

Бакет S3 с одной копией естественно встаёт на место одной из трёх. Несколько схем, которые удовлетворяют правилу:

Каждая стрелка - отдельное задание со своим расписанием, и каждый блок можно потерять, не утянув за собой остальные. Разберём схему по блокам:

• Копия 1 - рабочие данные на сервере.
• Копия 2 - backup панели, которые хранятся не на той машине, которую защищают, и восстанавливаются одной кнопкой, - самое быстрое восстановление после повседневных ошибок.
• Копия 3 - бакет S3, который наполняет задание со своими учётными данными и своим сроком хранения. Он переживает удаление сервера, которое уносит с собой backup панели.
• Копия вне площадки - то, чего один бакет дать не может, если он находится в той же площадке, что и сервер. Этот пробел закрывает ежемесячное скачивание на диск дома или второй бакет у другого провайдера, наполняемый rclone sync из первого. Для хобби-проекта ежемесячного скачивания более чем достаточно; для бизнеса - автоматизируйте его.

Разделяйте учётные данные. Приложение не должно держать ключи, которыми можно удалить его собственные backup. Если сервер, на котором работает задание backup, скомпрометирован, злоумышленник получает все ключи, которые там есть, поэтому копия, которую задание удалить не может, - скачанная домой, - и есть ваша офлайн-«1» в 3-2-1-1-0.

Проверка, что всё восстанавливается#

Каждый уровень этой схемы ничего не стоит, пока восстановление из него не сработало. Раз в квартал восстанавливайтесь из каждой копии, а не только из самой удобной:

1. Из бакета: скачайте дамп или выполните restic restore latest --target /tmp/restore-test и загрузите результат во временную базу или на тестовый сервер.
2. Из копии вне площадки: откройте файл с домашнего диска и проверьте, что дата та, которую вы ожидаете.
3. Запишите, сколько заняло каждое восстановление. Скачивание 50 GB требует реального времени даже на быстром канале, и это время входит в ваш простой.

Статья проверка восстановления до того, как оно понадобится превращает это в чеклист.

FAQ#

Безопасен ли бакет с одной копией для backup?

Как одна копия из нескольких - да. Его риск сосредоточен в одной системе в одном месте, и именно для этого в 3-2-1 нужны остальные копии. Как единственный backup - нет, но это верно для любой отдельной системы хранения, с репликацией или без.

Заменяет ли репликация backup?

Нет. Репликация защищает от отказа оборудования и мгновенно копирует каждое удаление, перезапись и порчу данных. Backup защищает от ошибок, потому что хранит прошлое. Вам нужна история, а не только избыточность.

Сколько дней хранить backup?

Не меньше, чем может понадобиться, чтобы заметить проблему. Тихая порча данных или удалённая папка, в которую никто не заглядывает, могут оставаться незамеченными неделями, поэтому неделя ежедневных копий плюс несколько ежемесячных - разумный минимум для большинства сайтов и серверов.

Занимают ли backup место после удаления?

Нет, после удаления - нет: хранилище без версионирования освобождает место сразу. Исключение - брошенные multipart-загрузки: они занимают место, пока их не отменят, и не видны в обычном листинге.

Нужно ли шифровать backup в S3?

Да, всё, что содержит персональные данные или учётные данные. restic шифрует по умолчанию; дампы шифруйте перед загрузкой инструментом вроде age, а ключ расшифровки храните там, где он не зависит от того, жив ли сервер.