Как вы обычно делаете резервную копию своей базы данных?

Я использую mysql

Как часто вы делаете резервную копию своей базы данных?

Экспортируйте все данные в формат sql или cvs и храните их в папке ??

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

 > SHOW MASTER STATUS\G

на хозяине и

 > SHOW SLAVE STATUS\G

на раб. Думаю, MySQL5 покажет отставание от SHOW SLAVE STATUS.

Когда вы довольны тем, что ваш раб не отставал, вы можете делать резервные копии, выполнив

Остановите репликацию с помощью SLAVE STOP; на рабе
Сделать mysqldump --opt на подчиненном сервере.
Снова запустите репликацию с SLAVE START; на рабе

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

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

Пара случайных советов:

Не поддавайтесь соблазну сделать резервную копию файлов данных mysql на основе файлов. Это больше хлопот, чем того стоит, а дампы MySQL более гибкие.
Остерегайтесь таблиц блокировки mysqldump во время дампа.
Остерегайтесь несоответствий в дампе, если вы не заблокируете каждую таблицу во время дампа
Использовать mysqldump --opt, так как обычно это самый быстрый способ импортировать полученный SQL
Делайте дамп как можно чаще. Мы сбрасываем ежедневно, потому что у нас более 40 ГБ данных.
Время от времени проверяйте свои дампы на запасном сервере, чтобы убедиться, что они работают.

Я использую сценарий, который использует mysqldump для извлечения данных / схемы в файл для каждой базы данных. Резервное копирование данных выполняется обычным резервным копированием netbackup на ленту. Очевидно, вы можете добавить дополнительные навороты, но это упрощает базовый дамп.

#!/bin/sh
# Find out what databases are in mysql and back them up
# Delete old backups


STARTTIME=` date +%Y%m%d-%H%M `

#BACKUP_DIR="/usr/local/db_backups"
BACKUP_DIR="/var/local/db_backups"
LOGFILE="/var/log/db_backups.log"
USER="root"
PASSWD="<password>"
KEEP="7"

(
echo
echo " ---MySQL backups start ${STARTTIME} ---"
#delete any backup written more than ${KEEP} days ago
echo "Removing files over ${KEEP} days old from ${BACKUP_DIR}:"
/usr/bin/find  ${BACKUP_DIR} -mindepth 1 -mtime +${KEEP} -print -delete



echo
echo "Performing today's dumps"
#find each database running in this instance of mysl
for DB in ` echo "show databases;"|mysql -u${USER} -p${PASSWD} mysql |awk " NR>1 {print $1} " `
do
        #generate a backup file name based on the data base name
        BACKUP_FILE="${BACKUP_DIR}/${DB}-${STARTTIME}.sql"
        echo "Processing database ${DB} into file ${BACKUP_FILE}"
        # dump the database data/schema into the backup file
        mysqldump -u${USER} -p${PASSWD} --add-drop-table ${DB} > ${BACKUP_FILE}
        gzip ${BACKUP_FILE}
done

ENDTIME=` date +%Y%m%d-%H%M `
echo
echo " ---MySQL backups complete ${ENDTIME} ---"
echo
) >>  ${LOGFILE} 2>&1

Обычно резервное копирование баз данных выполняется один раз в день, если их нужно остановить, а затем резервные копии переносятся в область хранения для консолидации, а затем переносятся на ленту.

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

Резервные копии не должны храниться на серверах с данными в случае отказа оборудования.

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

Для программного обеспечения вы можете, например, взглянуть на бакула или Zmanda

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

Мы делаем полное резервное копирование один раз в день, а затем в соответствии с политикой каждого клиента отсеиваем старые резервные копии, обычно мы храним 4 последних ежедневных резервных копии (чтобы пережить выходные;), 4 последних воскресенья и 4 последних первых воскресенья месяца. После этого одна-две свалки в год отправляются в архив на вечное хранение.

Мы также храним журналы репликации столько, сколько можем позволить сэкономить дисковое пространство. Они также очень полезны в качестве инструмента отладки, поскольку точно фиксируют, кто, что и когда изменил.

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

Один из приемов резервного копирования - использовать таблицы innodb и параметр --single-transaction для дампа mysql, чтобы резервное копирование не блокировало базу данных во время ее работы.

Я использую Percona's Xtrabackup. это неблокируемое решение для резервного копирования InnoDB / XtraDB

Вся цель резервного копирования - возможность восстановления.

Я бы не стал защищать дамп CSV в качестве решения для резервного копирования; все, что он вам даст, - это необработанные данные. Помимо этого, есть еще много всего, особенно с базой данных. Описания таблиц, просмотры, сохраненные процессы, что угодно. Если у вас их нет, вы не сможете вернуть его обратно. Также необходимо рассмотреть приложение и конфигурацию RDBMS. У вас может быть много исправлений, которые вам также нужно будет установить в среде восстановления, чтобы довести ее до того же уровня. Возможно, вы используете какую-то особую конфигурацию, продиктованную требованиями ваших приложений. У вас даже может быть определенный набор настроек ОС, необходимых для оптимальной работы вашей базы данных. Все это также необходимо будет вернуть, и если у вас нет решения для резервного копирования, которое способно это сделать, это приведет к дальнейшим задержкам во времени восстановления, не говоря уже об отсутствии гарантии, что вы вернете его в том же виде, в каком оно было.

Для резервного копирования баз данных (и резервных копий в целом) я всегда предпочитаю использовать «настоящее» программное обеспечение для резервного копирования, которое может справиться со всем этим.

Совсем недавно я управлял серверами MySQL в EC2. Мы настраивали снимки EBS на 15-минутное задание cron, 3-5 снимков сохранялись.

Когда мы создавали «традиционные» серверы MySQL, мы ежедневно делали резервные копии через MySQl-ZRM. Резервные копии, по сути, представляют собой mysqldump, которые отправляются на ленту, SAN и т. Д., В зависимости от потребностей клиента.

Оба метода можно использовать без остановки базы данных.

Для MySQL я использую automysqlbackup (http://sourceforge.net/projects/automysqlbackup/), поскольку моя программа резервного копирования (Backup Exec) не поддерживает моментальные снимки в системах Linux.

Он работает нормально, но я собираюсь следить за предложениями в этой ветке :)

Мы делаем резервные копии дважды в день, а также запускаем резервные копии журналов каждые 10-15 минут.

Преимущество этого метода заключается в том, что вы можете выполнить восстановление из одной из резервных копий дважды в день, а затем применить файлы журнала не позднее, чем за последние 15 минут. Таким образом вы сводите к минимуму количество данных, которые вы можете потерять.

Однако как часто вы будете делать резервные копии своих данных, решать вам. Сколько данных вы можете потерять? Если вы можете позволить себе потерять данные на несколько дней, выполняйте резервное копирование один раз в день. Данные никогда не меняются? Тогда вам понадобится всего одна копия!