Перейти на PRO

Какие сценарии резервного копирования (backup) данных вы знаете?

Тип вопроса: Управление тестированием Вероятность: 10% Категория: QA Тестировщик

Ответ

Сценарии резервного копирования определяют стратегию создания и хранения копий данных для восстановления. Основные подходы:

  1. Полный бэкап (Full Backup)

    • Что: Копируются все выбранные данные.
    • Плюсы: Простота и скорость восстановления (все данные в одном месте).
    • Минусы: Требует много времени и места.
    • Пример (SQL Server): 
      BACKUP DATABASE MyDatabase TO DISK = 'C:BackupsMyDB_Full.bak';

  2. Инкрементный бэкап (Incremental Backup)

    • Что: Копируются только данные, изменённые с момента последнего любого бэкапа (полного или инкрементного).
    • Плюсы: Быстрее и занимает меньше места, чем полный бэкап.
    • Минусы: Восстановление сложнее — требуется цепочка: последний полный бэкап + все последующие инкрементные.
    • Пример: 
      # Использование tar с ключом --newer для инкрементного архивирования
tar --create --file=backup_inc.tar --newer='2023-10-01' /data/

  3. Дифференциальный бэкап (Differential Backup)

    • Что: Копируются данные, изменённые с момента последнего полного бэкапа.
    • Плюсы: Восстановление проще, чем при инкрементном: нужен только последний полный бэкап и последний дифференциальный.
    • Минусы: Со временем размер бэкапа растёт.
    • Пример (SQL Server): 
      BACKUP DATABASE MyDatabase TO DISK = 'C:BackupsMyDB_Diff.bak' WITH DIFFERENTIAL;

  4. Резервное копирование журналов транзакций (Transaction Log Backup)

    • Что: Применяется в СУБД (SQL Server, PostgreSQL). Копируется журнал транзакций, что позволяет восстановить базу до момента во времени.
    • Плюсы: Точное восстановление (Point-in-Time Recovery).
    • Минусы: Требует полной модели восстановления БД.
    • Пример: 
      BACKUP LOG MyDatabase TO DISK = 'C:BackupsMyDB_Log.trn';

Практические аспекты:

  • Правило 3-2-1: Храните 3 копии данных, на 2 разных типах носителей, 1 из которых — в другом месте.
  • Автоматизация: Использование планировщиков (cron в Linux, Task Scheduler в Windows) или облачных сервисов (AWS Backup, Azure Backup).
  • Тестирование восстановления: Критически важная практика. Регулярно проверяйте, что из резервной копии можно восстановить данные.

Ответ 18+ 🔞

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

Вот смотри, есть несколько способов не остаться с носом, когда сервак плюнул в потолок.

1. Полный бэкап (Full Backup) Это когда ты, как конченый максималист, берешь и копируешь ВСЁ до последнего байта. Весь этот цифровой хлам.

  • Чем хорош? Восстановить — раз плюнуть. Один файл, один раз — и ты как новенький.
  • Чем говён? Время и место жрёт, как Герасим щи. Овердохуища.
  • Выглядит это примерно так: 
    BACKUP DATABASE MyDatabase TO DISK = 'C:BackupsMyDB_Full.bak';

    Вот и вся философия. Сделал и спи спокойно, пока место на диске не кончится.

2. Инкрементный бэкап (Incremental Backup) А это уже для хитрожопых. Копируется только то, что поменялось с прошлого раза, неважно какого — полного или такого же инкрементного.

  • Плюсы: Быстро, мало места надо. Идеально для ежедневных дел.
  • Минусы: Восстановление — это пиздец и головная боль. Нужно сначала вкатить последний полный бэкап, а потом по очереди все инкрементные, которые после него были. Один файл проебал — и вся цепочка к херам.
  • Примерчик: 
    tar --create --file=backup_inc.tar --newer='2023-10-01' /data/

3. Дифференциальный бэкап (Differential Backup) Золотая середина, ёпта. Копируем всё, что изменилось с момента последнего полного бэкапа.

  • Плюсы: Восстанавливать уже проще. Всего два файла нужны: последний полный и последний дифференциальный. Не нужно городить цепь.
  • Минусы: Чем дальше от полного бэкапа, тем этот файл жирнее. К концу недели может сравниться с полным.
  • В коде: 
    BACKUP DATABASE MyDatabase TO DISK = 'C:BackupsMyDB_Diff.bak' WITH DIFFERENTIAL;

4. Бэкап журналов транзакций (Transaction Log Backup) Это уже высший пилотаж для СУБД. Сохраняем не данные, а историю всех операций — журнал.

  • Плюсы: Мощнейшая штука. Можно откатить базу до конкретной секунды. "Верни, как было вчера в 14:30, перед тем как Петрович накосячил".
  • Минусы: Чтобы это работало, база должна быть в особом режиме, и за этим надо следить.
  • Делается так: 
    BACKUP LOG MyDatabase TO DISK = 'C:BackupsMyDB_Log.trn';

А теперь, блядь, самое главное, что все просрать могут:

  • Правило 3-2-1. Заучи как "Отче наш". 3 копии данных. 2 разных типа носителя (например, диск и облако). 1 копия — в другом городе/офисе, на случай если тут пожар или пидары налетели.
  • Автоматизация. Ты что, каждый день вручную это делать будешь? Настрой cron, Task Scheduler или облачный сервис. Пусть работают сами.
  • Тестирование восстановления. Вот это, сука, главное. Ты можешь делать бэкапы до посинения, но если ни разу не пробовал из них восстановиться — доверия к ним ебать ноль. Регулярно проверяй, что твои файлы не битые и из них реально можно всё поднять. Иначе получится история, как с Герасимом — сделал дело, а потом мучайся с совестью, когда всё уже на дне.
© ХакСобесов, 2026
support@hacksobesov.com