Назад | Перейти на главную страницу

Лучшие практики для резервного копирования баз данных

Я спросил об этом переполнение стека, но кто-то указал, что лучше спросить здесь.

Предположим, что Subversion и MySQL на RAID NAS. Каковы лучшие практики резервного копирования данных?

Я думал поставить mysqldumps под контроль subversionn, а затем, возможно, периодически выполнять резервное копирование репозитория svn путем 7zip целиком.

Если вы не храните резервные копии svn на другом физическом жестком диске, создание резервных копий репозитория вряд ли поможет. Это правда? Если нет, то почему?

Наконец, как часто следует делать резервные копии и сколько сохранять?

Во-первых, не контролируйте версии резервных копий базы данных.
Резервная копия - это резервная копия - момент времени. Использование контроля версий звучит неплохо, но помните, что это означает, что вам нужно будет восстановить весь репозиторий SVN (ZOMG Freaking ОГРОМНЫЙ), если у вас катастрофический сбой и вам нужно вернуть свою базу данных. Это может быть дополнительное время простоя, которое вы не можете себе позволить.

Во-вторых, убедитесь, что ваши резервные копии каким-то образом удаляются с сайта. Резервная копия на локальной машине отлично подходит, если вам нужно восстановить данные, потому что вы испортили и уронили таблицу. Абсолютно бесполезно, если диски вашего сервера умрут.
Варианты включают внешний жесткий диск или отправку резервных копий на удаленную машину с помощью rsync. Есть даже поставщики услуг хранения как rsync.net которые специализируются на этом.

В-третьих, относительно частоты резервного копирования: как часто это нужно делать, знаете только вы.
У моей нынешней компании есть подчиненная база данных с репликацией наших производственных данных почти в реальном времени. Резервное копирование этого ведомого устройства выполняется каждую ночь на локальный компьютер, который затем синхронизируется с удаленным хранилищем.
В случае отказа производственного оборудования мы активируем подчиненное устройство. Потеря данных должна быть минимальной, как и время простоя. В случае случайного удаления таблицы мы можем восстановить ее из локальной резервной копии (потеря данных до 1 дня). В случае катастрофического инцидента мы можем восстановить данные из внешней резервной копии (что занимает некоторое время, но опять же приведет к потере данных только за 1 день).
Будет ли такая схема резервного копирования работать для вас, зависит от ваших данных: если они часто меняются, вам может потребоваться изучить стратегию резервного копирования, которая обеспечивает восстановление на определенный момент времени (решения по доставке журналов часто могут это сделать). Если он в основном статичен, вам может потребоваться резервное копирование только раз в месяц. Главное - убедиться, что вы фиксируете изменения в своих данных в разумные сроки с момента их внесения, чтобы не потерять эти изменения в случае серьезного инцидента.

общий совет:

  • следите за своими резервными копиями
    • проверьте, успешно ли они закончили [например, обычный результат mysqldump в поисках финишной черты; проверить коды ошибок, возвращаемые командами дампа],
    • если размер резервной копии разумный
  • время от времени проводить тесты восстановления - может быть, каждые 3-6 месяцев
  • резервное копирование на автономный носитель, чтобы вы не потеряли данные в случае злонамеренной атаки
  • храните резервные копии вне офиса, чтобы не потерять данные в случае стихийного бедствия

конкретный совет:

  • mysqldumps, перекачиваемый в svn для управления версиями, звучит как излишество - удалить что-либо из svn довольно сложно. как насчет использования rdiff-резервное копирование сохранить последнюю резервную копию и несколько предыдущих?
  • svn - используйте svnadmin dump - это «правильный» способ получения дампов svn
  • если вы хотите быть в большей безопасности - используйте lvm и сделайте дополнительно снимки lvm каталогов данных mysql и svn
  • использовать механизм хранения innodb, чтобы резервные копии не блокировались

При подготовке стратегии резервного копирования следует начать с оценки целевой точки восстановления (RPO) и целевого времени восстановления (RTO). RPO указывает, сколько данных бизнес готов потерять в случае инцидента, а RTO указывает, как быстро потребуется восстановление. Ваши требования к RTO и RPO повлияют на экономические затраты и затраты на обслуживание резервного копирования. [1].

Обычно существует четыре стратегии резервного копирования:

  • Реплика сервера: использование другого сервера, физически и логически отделенного от основного сервера базы данных, и всякий раз, когда данные записываются в базу данных, также записываются в реплицируемую базу данных.
  • Дамп базы данных: периодически выгружать базу данных в файл и отправлять этот файл на сервер резервного копирования.
  • Снимок базы данных: используйте любой инструмент для создания снимков файловой системы, например rsnapshot для периодического создания моментальных снимков основных файлов данных базы данных и отправки их на сервер резервного копирования.
  • На основе облака и агента: вы устанавливаете агент только на свой сервер базы данных и периодически выполняете резервное копирование в облако.

У каждого подхода есть свои плюсы и минусы, их можно сравнивать с разных точек зрения:

  • Неблокирующий: все методы не должны останавливать доступ на запись в базу данных для резервного копирования, кроме Снимок базы данных что в некоторых случаях, например в mongodb, когда ведение журнала включено, даже с моментальным снимком LVM нет гарантии, что моментальный снимок является непротиворечивым и действительным.

  • Инкрементальный: dump и моментальный снимок обычно не являются инкрементными, и, следовательно, скорость резервного копирования ниже, чем у остальных. методы реплики и облака носят инкрементный характер.

  • Нагрузка: snapshot не загружает базу данных, поскольку копируются только базовые файлы. дамп имеет наибольшую нагрузку. В другом методе нагрузка распределяется по часам работы базы данных.