Я спросил об этом переполнение стека, но кто-то указал, что лучше спросить здесь.
Предположим, что Subversion и MySQL на RAID NAS. Каковы лучшие практики резервного копирования данных?
Я думал поставить mysqldumps под контроль subversionn, а затем, возможно, периодически выполнять резервное копирование репозитория svn путем 7zip целиком.
Если вы не храните резервные копии svn на другом физическом жестком диске, создание резервных копий репозитория вряд ли поможет. Это правда? Если нет, то почему?
Наконец, как часто следует делать резервные копии и сколько сохранять?
Во-первых, не контролируйте версии резервных копий базы данных.
Резервная копия - это резервная копия - момент времени. Использование контроля версий звучит неплохо, но помните, что это означает, что вам нужно будет восстановить весь репозиторий SVN (ZOMG Freaking ОГРОМНЫЙ), если у вас катастрофический сбой и вам нужно вернуть свою базу данных. Это может быть дополнительное время простоя, которое вы не можете себе позволить.
Во-вторых, убедитесь, что ваши резервные копии каким-то образом удаляются с сайта. Резервная копия на локальной машине отлично подходит, если вам нужно восстановить данные, потому что вы испортили и уронили таблицу. Абсолютно бесполезно, если диски вашего сервера умрут.
Варианты включают внешний жесткий диск или отправку резервных копий на удаленную машину с помощью rsync. Есть даже поставщики услуг хранения как rsync.net которые специализируются на этом.
В-третьих, относительно частоты резервного копирования: как часто это нужно делать, знаете только вы.
У моей нынешней компании есть подчиненная база данных с репликацией наших производственных данных почти в реальном времени. Резервное копирование этого ведомого устройства выполняется каждую ночь на локальный компьютер, который затем синхронизируется с удаленным хранилищем.
В случае отказа производственного оборудования мы активируем подчиненное устройство. Потеря данных должна быть минимальной, как и время простоя. В случае случайного удаления таблицы мы можем восстановить ее из локальной резервной копии (потеря данных до 1 дня). В случае катастрофического инцидента мы можем восстановить данные из внешней резервной копии (что занимает некоторое время, но опять же приведет к потере данных только за 1 день).
Будет ли такая схема резервного копирования работать для вас, зависит от ваших данных: если они часто меняются, вам может потребоваться изучить стратегию резервного копирования, которая обеспечивает восстановление на определенный момент времени (решения по доставке журналов часто могут это сделать). Если он в основном статичен, вам может потребоваться резервное копирование только раз в месяц. Главное - убедиться, что вы фиксируете изменения в своих данных в разумные сроки с момента их внесения, чтобы не потерять эти изменения в случае серьезного инцидента.
общий совет:
конкретный совет:
При подготовке стратегии резервного копирования следует начать с оценки целевой точки восстановления (RPO) и целевого времени восстановления (RTO). RPO указывает, сколько данных бизнес готов потерять в случае инцидента, а RTO указывает, как быстро потребуется восстановление. Ваши требования к RTO и RPO повлияют на экономические затраты и затраты на обслуживание резервного копирования. [1].
Обычно существует четыре стратегии резервного копирования:
У каждого подхода есть свои плюсы и минусы, их можно сравнивать с разных точек зрения:
Неблокирующий: все методы не должны останавливать доступ на запись в базу данных для резервного копирования, кроме Снимок базы данных что в некоторых случаях, например в mongodb, когда ведение журнала включено, даже с моментальным снимком LVM нет гарантии, что моментальный снимок является непротиворечивым и действительным.
Инкрементальный: dump и моментальный снимок обычно не являются инкрементными, и, следовательно, скорость резервного копирования ниже, чем у остальных. методы реплики и облака носят инкрементный характер.
Нагрузка: snapshot не загружает базу данных, поскольку копируются только базовые файлы. дамп имеет наибольшую нагрузку. В другом методе нагрузка распределяется по часам работы базы данных.