Резервное копирование БД с помощью Git - хорошая идея?

То, как я вижу, что он сбрасывает базу данных PostgeSQL в один большой файл SQL, а затем совершает и нажимает на удаленный репозиторий Git, может быть потрясающим решением для резервного копирования: я получаю историю всех версий, хеширование, безопасный транспорт, один (очень сложно испортить и удалить данные путем нажатия), эффективное хранилище (при отсутствии двоичных файлов) и отсутствие возможности нового изображения, искажающего резервную копию (что представляет собой риск с помощью rsync).

Кто-нибудь использовал этот подход, особенно с pg, и может поделиться своим опытом? Ловушки?

Ответ 1

Вот подробные сведения о том, как это сделать для postgres.

Создать пользователя резервного копирования

Сценарии предполагают существование пользователя под названием "backup", который имеет доступ ко всем (суперпользователю) или к конкретной базе данных. Учетные данные хранятся в файле .pgpass в домашнем каталоге. Этот файл выглядит так (предполагая, что пароль "секретный" ).

~/.pgpass

*:*:*:backup:secret

Убедитесь, что вы установите правильную защиту на .pgpass или проигнорируете ее

chmod 0600 ~/.pgpass

Резервное копирование единой базы данных

Отбрасывает определенную базу данных.

backup.sh

pg_dump dbname -U backup > backup.sql
git add .
git commit -m "backup"
git push origin master

Примечание. Вероятно, вы не хотите использовать какие-либо параметры разделения файлов для дампа БД, поскольку любая вставка/удаление приведет к эффекту "домино" и изменит все файлы, создавая больше дельт/изменений в git.

Резервное копирование всех баз данных на этом компьютере

Этот script сбрасывает весь кластер базы данных (все базы данных):

pg_dumpall -U backup > backup.sql
git add .
git commit -m "backup"
git push origin master

Запланируйте его для запуска

Последний шаг - добавить это к заданию cron. Итак, "crontab -e", а затем добавьте что-то вроде следующего (работает каждый день в полночь)

# m h  dom mon dow   command
# run postgres backup to git
0 0 * * * /home/ubuntu/backupdbtogit/backup.sh

Восстановление

Если вам нужно восстановить базу данных, вы проверите версию, которую хотите восстановить, а затем перейдите к pg. (подробнее об этом здесь http://www.postgresql.org/docs/8.1/static/backup.html#BACKUP-DUMP-RESTORE)

для одной базы данных:

psql dbname < infile

для всего кластера

psql -f infile postgres

Ничто из этого не было особенно сложным, но оно всегда утомительно смотрело на все части.

Сбой на сервере с ограниченной оперативной памятью

У меня возникла проблема с git неудачей при нажатии. Это связано с тем, что git использовал много памяти - несколько коммитов поддержали. Я разрешил сбой, установив сервер git repo на моем локальном компьютере (в котором много ОЗУ). Я установил серверный диск с помощью sshfs, а затем зафиксировал его на своей рабочей станции. После того, как я это сделал, сервер с низкой памятью возобновил работу без проблем.

Лучшей альтернативой является ограничение использования памяти git во время пакета (от Есть ли способ ограничить объем памяти, который "git gc" использует?).

git config --global pack.windowMemory "100m"
git config --global pack.packSizeLimit "100m"
git config --global pack.threads "1"

Примечание. Я еще не пробовал устанавливать ограничение памяти, так как у меня еще не была проблема с откатом.

Ответ 2

Я бы определенно рекомендовал его. Люди тоже это делают, в основном вокруг MySQL, но я не думаю, что есть большая разница:

http://www.viget.com/extend/backup-your-database-in-git/

Другой подход - использование моментальных снимков ZFS для резервных копий.

http://www.makingitscale.com/2010/using-zfs-for-fast-mysql-database-backups.html

Ответ 3

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

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

Если вы говорите только о схеме, вы, вероятно, не можете ошибиться с "резервными копиями", используя Git. Но если вы хотите создать резервную копию данных, все может усложниться. Git не очень хорош с большими файлами. Вы можете использовать что-то вроде git -annex для решения этой проблемы, но для создания внешних файлов вам нужен отдельный механизм резервного копирования. Кроме того, использование "правильных" методов резервного копирования, таких как архивирование pg_dump или WAL, дает другие преимущества, такие как возможность восстановления подмножеств баз данных или восстановление моментально.

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

Ответ 4

Я сделал это в $day_job, но это с MySQL.

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

script разбивает монолитный sql файл на отдельные таблицы и данные таблицы sql.

Я также должен был гарантировать, что каждый оператор вставки sql не находится в одной строке, чтобы иметь читаемые отчеты diff.

Одним из преимуществ сохранения дампа в git является то, что я могу запустить "git log -stat", чтобы получить обзор того, какие таблицы были изменены между версиями "резервной копии".