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

Question

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

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

Answer 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.

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

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

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

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

Запланировать запуск

Последний шаг - добавить это в задание 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-репозиторий на своей локальной машине (на которой много оперативной памяти). Я смонтировал диск сервера с помощью sshfs, а затем зафиксировал его с моей рабочей станции. После того, как я это сделал, сервер с низкой памятью возобновил фиксацию без проблем.

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

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

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

Answer 2

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

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

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

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

Answer 3

Я бы определенно рекомендовал это.Люди тоже этим занимаются, в основном вокруг 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

Answer 4

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

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

Скрипт разбивает монолитный файл SQL на отдельные схемы и данные таблицы SQL.

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

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