Я хочу автоматизировать резервное копирование моих баз данных и файлов с помощью cron. Следует ли мне добавить в crontab следующие строки?
mysqldump -u root -pPASSWORD database_name | gzip > /home/backup/database_`date +\%m-\%d-\%Y`.sql.gz
svn commit -m "Committing the working copy containing the database dump"
Прежде всего, это хороший подход?
Непонятно, как указать репозиторий и рабочую копию с помощью svn?
Как я могу запустить svn только после завершения mysqldump, а не раньше? Избегать конфликтов
1) Если вы настаиваете на хранении резервных копий в Subversion, то в этом подходе нет ничего плохого. Хотя это странно.
2) Вы должны держать кассу, поместить дамп в рабочий каталог и запустить svn update и svn add по мере необходимости перед совершением.
3) Если вы запускаете команды, как показано в сценарии оболочки, перекрытия быть не должно.
Также обратите внимание, что сжатие вывода mysql создаст совершенно разные двоичные файлы и приведет к увеличению требований к диску репозитория. Для несжатого sql может потребоваться больше начального места, но текстовые различия будут храниться в репозитории гораздо эффективнее. Также нет необходимости хранить каждый файл как отдельный файл с датой в имени. Это может быть тот же файл, поскольку контроль версий позволяет повернуть время вспять.
Я предпочитаю скользящее резервное копирование с чем-то вроде заархивированного sql за последние 7 дней, а затем моментальные снимки с интервалом в одну неделю на месяц или два. Я не вижу необходимости вечно контролировать версию базы данных.
Как я уже сказал, сохранение БД в репозитории SVN не является хорошей практикой.
Что касается mysqldump, имейте в виду, что таким образом вы также включаете эти параметры (--opt по умолчанию является сокращением нижеприведенного):
--add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset
Таким образом, если вы будете использовать созданный вами полный дамп, вы перезапишете все данные, которые вы вставили после последнего выполненного резервного копирования.
Пока ваша БД не станет такой маленькой, как вы сказали, я советую вам чаще делать резервную копию.
это - хороший пример того, как вы можете продолжить.
Если ваша БД большая, хранение сотен копий базы данных будет превышать емкость вашего хранилища, что, вероятно, застает вас неподготовленным и занятым чем-то другим. сжатие gzip почти наверняка повредит, так как это препятствует Возможность SVN сжимать между ревизиями, и я думаю, что SVN уже использует внутреннюю zip-библиотеку. Вы можете потратить несколько дней на резервное копирование и попробовать оба способа и посмотреть, какой из них использует меньше диска. Возможно, также будет полезно каким-то образом заказать дамп, например, с помощью --order-by-primary; в противном случае SVN придется тратить диск, представляя легкомысленные переупорядочения mysqldump, которые вас не волнуют.
Но в конце концов вам придется просто отбросить данные. Один интересный подход, который я видел, получил название «логарифмическое резервное копирование». Идея состоит в том, что новые резервные копии более важны, чем старые, поэтому вы сохраняете их больше, а срок действия большинства из них истекает по мере их старения. Итак, вы в конечном итоге
Это аналогичный подход к RRDtool, где данные объединяются в репрезентативный объект. В итоге у вас будет 20+ резервных копий и возможность восстанавливать краткосрочные данные из недавнего прошлого и долгоживущие данные из далекого прошлого.
Собственно отвечая на вопрос
Поскольку ваши данные относительно малы и, вероятно, не сильно меняются, SVN может быть неплохим подходом.
У меня есть аналогичный процесс для размещения интересующих веб-сайтов в SVN, который я модифицировал в соответствии с вашими потребностями. Поместите это в свой cron.daily или где-нибудь еще, и вы сделаете это. Сначала вам нужно будет инициализировать репо и настроить его в соответствии с вашими потребностями, но это хорошее начало:
#!/bin/bash
# check out to temp dir
DIR=`mktemp -d`
cd $DIR
# check out repository
svn co $1 .
# dump db
mysqldump --order-by-primary -u root -pPASSWORD database_name
# if changed, commit
svn commit -m 'Nightly backup'
cd ..
rm -rf $DIR
Как насчет того, чтобы сделать автоматический дамп резервной копии с помощью automysqlbackup, а затем создать автоматически управляемые полные / различия с помощью BackupPC?
BackupPC устанавливает жесткие связи между неизмененными файлами в разных резервных копиях, чтобы минимизировать использование дискового пространства.
Сброс вашей базы данных в файл и фиксация этого файла в svn - прекрасный подход. Однако есть несколько вещей, которые я рекомендую изменить ... Вы должны перезаписывать один и тот же файл каждый раз при сбросе (удаляйте дату из имени файла) и удаляйте zip.
Как и при редактировании исходного кода, вы, по сути, изменяете файл дампа базы данных. Кроме того, как уже упоминалось, если вы не заархивируете его, в конечном итоге он будет намного лучше сжиматься на сервере, потому что различия будут намного меньше.
Самое замечательное в этом подходе заключается в том, что он связывает базу данных с кодом в определенное время. Например, вам нужно запустить ревизию 1428. Нет проблем ... обновите локальное репо до версии 1428, и у вас будет весь код и дамп базы данных, который работает с 1428. Загрузите этот дамп, скомпилируйте свой код, и вы в делах.