Недавно у нас вышла статья про бэкапы, где было много разных терминов. Так как в один материал сложно вместить всё, что хочется сказать по теме, мы составили отдельный словарь по бэкапам: какие там есть термины, что они означают и в каких ситуациях используются.
Бэкап (Backup)
Что это: бэкап — это резервная копия ваших данных, своеобразная «страховка» на случай непредвиденных обстоятельств. Представьте, что вы делаете фотографию важного документа перед тем, как отправить его по почте: если оригинал потеряется, у вас останется копия.
Бэкапы нужны в самых разных ситуациях. Например, когда сервер выходит из строя из-за аппаратных проблем или когда кто-то из сотрудников случайно удаляет важные файлы. Они также защищают от кибератак, таких как вирусы-шифровальщики, которые могут заблокировать доступ к данным.
Существуют разные виды бэкапов. Полный бэкап сохраняет все данные целиком, инкрементальный — только то, что изменилось с момента последнего копирования, а дифференциальный — все изменения после последнего полного бэкапа.
👉 Допустим, у вас есть важный файл с кодом проекта. Простейший бэкап в Linux можно сделать одной командой:
cp project_code.py project_code_backup.pyРепликация (Replication)
Что это: репликация — процесс автоматического копирования данных с одного сервера на другой, причём копия обновляется в реальном времени.
Главная цель репликации — обеспечить бесперебойную работу системы. Если основной сервер перестаёт отвечать, система мгновенно переключается на резервный, и пользователи даже не замечают проблем. Это особенно важно для банковских систем, интернет-магазинов и других сервисов, где простои недопустимы.
Репликация бывает синхронной и асинхронной. В первом случае данные записываются на оба сервера одновременно, что гарантирует полную идентичность копий, но немного замедляет работу. Асинхронная репликация работает быстрее, но возможна небольшая задержка между обновлением основного сервера и его копии.
В MySQL репликация настраивается примерно так (да простят нас девопсы и админы):
CHANGE MASTER TO
MASTER_HOST='primary_server',
MASTER_USER='replica_user';
START SLAVE;Снимок (Snapshot)
Что это: снимок — моментальная «фотография» состояния системы или диска в определённый момент времени.
Снимки часто используются при работе с виртуальными машинами. Например, перед обновлением ПО можно сделать снапшот — если что-то пойдёт не так, вы всегда сможете вернуться к предыдущему состоянию. Также снимки удобны для тестирования: можно быстро развернуть копию рабочей среды, не затрачивая ресурсы на полное развёртывание.
При этом важно помнить, что снимки — это не полноценные бэкапы. Они хранятся на том же физическом носителе, что и исходные данные, поэтому, если диск выйдет из строя, пропадёт и снапшот.
Как можно создать снимок для VMware (виртуальной машины):
vim-cmd vmsvc/snapshot.create 1 "Before Update"Восстановление (Restore)
Что это: восстановление — это процесс возврата данных из резервной копии в рабочую среду.
Восстановление может потребоваться в разных ситуациях: после случайного удаления файлов, при повреждении базы данных или при переносе системы на новый сервер. Время восстановления зависит от объёма данных и типа бэкапа — от нескольких секунд для одного файла до нескольких часов для целого сервера.
Тут важно регулярно проверять, что бэкапы действительно работают. Бывали случаи, когда в критический момент оказывалось, что резервные копии повреждены или содержат устаревшие данные.
Как можно восстановить БД PostgreSQL (самый простой способ):
psql -U user -d dbname < backup.sqlRPO и RTO
Что это: RPO и RTO — это два ключевых показателя, которые помогают оценить эффективность системы резервного копирования.
RPO (Recovery Point Objective) определяет, сколько данных вы можете позволить себе потерять. Например, если RPO равен одному часу, значит, бэкапы должны создаваться не реже чем раз в 60 минут.
RTO (Recovery Time Objective) показывает, как быстро система должна вернуться к работе после сбоя. Для критически важных сервисов RTO может составлять минуты, тогда как для второстепенных систем допустимы часы простоя.
Эти параметры напрямую влияют на выбор стратегии бэкапирования. Например, для почтового сервера с RPO = 5 минут потребуется частое резервное копирование, а для тестовой среды с RTO = 24 часа можно использовать более простые решения.
Допустим, у вас есть интернет-магазин. Вы решили, что:
- RPO = 1 час → значит, бэкапы нужно делать каждые 60 минут.
- RTO = 30 минут → значит, нужно убедиться, что за это время вы подготовите бэкапы для быстрого восстановления.
Архивация (Archiving)
Что это: долгосрочное хранение данных, которые уже не используются активно, но могут понадобиться в будущем. Важно понимать, что архивация — это не то же самое, что резервное копирование.
👉 Резервные копии создаются для быстрого восстановления текущих данных в случае аварии, тогда как архив предназначен для хранения информации «на всякий случай». Архивные данные обычно не требуют быстрого доступа, но должны сохраняться в целости долгие годы.
Архивация полезна для хранения финансовой отчётности прошлых лет, завершённых проектов, устаревших, но потенциально полезных данных. Например, дизайн-студия может архивировать исходники старых проектов — вдруг клиент через несколько лет попросит поиграть со шрифтами.
Для архивации обычно выбирают ёмкие и недорогие носители: магнитные ленты, большие HDD-диски или специализированные облачные сервисы с холодным хранением. Данные часто сжимают и упаковывают в архивные форматы, чтобы сэкономить место.
Облачный бэкап (Cloud Backup)
Что это: подход к резервному копированию, когда ваши данные хранятся не на локальных устройствах, а на удалённых серверах, доступных через интернет.
Главный плюс облачного бэкапа — защита от физических угроз. Даже если в офисе случится пожар или потоп, ваши данные останутся в безопасности. Кроме того, вы получаете доступ к резервным копиям из любой точки мира и обычно платите только за фактически используемое место.
А ещё такие бэкапы хороши для защиты особо ценных личных данных — семейных фотоархивов, важных документов.
Дедупликация (Deduplication)
Представьте, что вы храните 100 одинаковых фотографий кота. Так вот, дедупликация — это когда вы оставляете одну оригинальную фотографию, а остальные 99 заменяете ссылкой на неё. Так работает эта технология, только вместо котиков — ваши данные.
👉 Допустим, у вас есть 50 серверов с одинаковой операционной системой. Без дедупликации вы сохраните 50 копий ОС. С ней — только одну. Это экономит место, деньги на дисках и ускоряет передачу данных. Или ваш коллега отправил всем в отдел PDF-отчёт на 100 МБ. Дедупликация на почтовом сервере сохранит его один раз, а не 30 раз — как если бы каждый сотрудник хранил свою копию.
Лучше всего это работает в облачных хранилищах вроде AWS или Backblaze, где тысячи пользователей могут хранить похожие файлы. Или в больших компаниях, где сотрудники работают с одними и теми же шаблонами документов.
Инкрементальный бэкап (Incremental Backup)
Что это: очень похоже на то, как вести дневник, где вы записываете только то, что произошло за день, а не переписываете всю жизнь с нуля.
После полного бэкапа система запоминает, как выглядели данные в этот момент. Каждый следующий инкрементальный бэкап сохраняет только новые изменения. Например:
- Понедельник — полный бэкап всей папки «Проект X».
- Вторник — сохранился новый файл «отчёт.docx», который вы делали во вторник с утра.
- Среда — добавились изменения в «база_данных.sql», которые вы внесли в среду.
❗️ Чтобы восстановить данные на среду, вам понадобится полный бэкап понедельника + инкрементальные копии вторника и среды. Если потеряется хотя бы одно звено — восстановление усложнится (или восстановить вообще ничего не получится, если систему жизнь к такому не готовила).
Полный бэкап (Full Backup)
Это как сделать ксерокопию всей вашей записной книжки — каждая страница, каждая пометка, даже рисунки на полях. И обложку тоже.
Когда без него не обойтись:
- При первом запуске системы бэкапов.
- Перед важными изменениями (например, обновлением сервера).
- Раз в неделю/месяц для создания «точки отсчёта».
Для восстановления нужен только один этот бэкап (и иногда это просто один огромный файл) и он не зависит от других копий. Правда, полный бэкап занимает много места (если у вас 1 ТБ данных, полный бэкап займёт ~1 ТБ) и очень долго создаётся (может иногда часами).
👉 А ещё лучше хранить минимум две последние полные копии. Если одна повредится — будет запасная. Добро пожаловать в ИТ.
Дифференциальный бэкап (Differential Backup)
Что это: золотая середина между полным и инкрементальным бэкапом.
Допустим, в воскресенье вы сделали полный бэкап.
- Понедельник: сохраняются изменения после воскресенья.
- Вторник: сохраняются ВСЕ изменения с воскресенья (даже те, что уже были в понедельнике).
- Среда: снова ВСЕ изменения с воскресенья.
Выглядит параноидально, но принцип общий: мы сначала делаем исходную точку, а потом каждый день записываем изменения, которые произошли с того момента (а не за предыдущий день, в отличие от инкрементального).
Удобно тем, что для восстановления нужен только полный бэкап + последний дифференциальный. Не надо собирать цепочку из десятка файлов, как с инкрементальными.
👉 Такая штука хорошо пригождается для еженедельного резервирования базы данных интернет-магазина, где данные меняются каждый день, но полный бэкап делать дорого.
Холодный бэкап (Cold Backup)
Как работает: вы выключаете программу, останавливаете сервер и только потом копируете данные. Это как фотографировать спящего кота — он точно не шевелится.
Так делают, чтобы гарантировать, что во время копирования никто не изменит данные. Особенно важно для баз данных вроде MySQL или PostgreSQL, где одновременная запись и бэкап могут привести к ошибкам.
Правда, при таком способе есть минус: сервис будет недоступен, пока идёт копирование. Поэтому такие бэкапы обычно делают ночью или в часы минимальной нагрузки:
Магазин закрывается в 22:00 → кассир делает Z-отчёт → база данных останавливается → делается бэкап → утром магазин снова открывается.
Горячий бэкап (Hot Backup)
Что это: возможность делать бэкап без остановки работы всей системы. Если продолжать аналогию с фото, это как снять бегущего кота так, чтобы снимок получился чётким.
Чтобы это получилось, специальные механизмы (например, транзакционные журналы в базах данных) фиксируют состояние системы на конкретный момент. Даже если данные продолжают меняться, бэкап сохраняет их «замороженную» версию. Подход хорошо работает в банковских системах, онлайн-кинотеатрах, соцсетях — везде, где простой недопустим даже на минуту.
Вот пример горячего бэкапа для PostgreSQL:
pg_dump -U user -h localhost dbname --format=custom --file=backup.dumpПравило 3-2-1 (3-2-1 Rule)
Что это: золотое правило бэкапов, которое можно запомнить как «три копии, два носителя, один экземпляр в другом месте».
Допустим, у вас есть важный проект. По правилу 3-2-1 вы должны:
- Хранить основной файл на рабочем компьютере.
- Иметь две дополнительные копии.
- Использовать разные носители (например, внешний SSD и NAS).
- Один экземпляр должен быть в другом месте (например, в облаке или у родителей на флешке).
Если сгорит офис, украдут ноутбук или сломается диск, у вас всегда будет доступ к данным. Это как держать запасные ключи от дома в разных местах: вроде сильно замороченно, но когда вдруг что, это сильно выручает.
❗️ Главное правило любых бэкапов
Проверяйте, что бэкапы действительно работают, и хотя бы раз в месяц пробуйте восстановить данные из них. Однажды это сэкономит вам кучу времени и нервов.
Вам слово
Приходите к нам в соцсети поделиться своим мнением о словаре и терминах и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте: шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
