Назад | Перейти на главную страницу

GIT как инструмент резервного копирования

На сервере установите git

cd /
git init
git add .
git commit -a -m "Yes, this is server"

Тогда получите /.git/ чтобы указать на сетевой диск (SAN, NFS, Samba, что угодно) или другой диск. Используйте задание cron каждый час / день и т. Д., Чтобы обновлять изменения. Каталог .git будет содержать версионную копию всех файлов сервера (за исключением бесполезных / сложных, таких как / proc, / dev и т. Д.)

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

Ты не глупый человек. С помощью git как резервный механизм может быть привлекательным, и, несмотря на то, что говорят другие, git отлично работает с двоичными файлами. Читать эта страница из Git Book для получения дополнительной информации по этой теме. В основном, поскольку git не использует механизм дельта-хранилища, ему все равно какие ваши файлы выглядят так (но полезность git diff довольно низкий для двоичных файлов со стандартной конфигурацией).

Самая большая проблема с использованием git для резервного копирования заключается в том, что он не сохраняет большинство метаданных файловой системы. В частности, git не записывает:

  • группы файлов
  • владельцы файлов
  • права доступа к файлам (кроме "это исполняемый файл")
  • расширенные атрибуты

Вы можете решить эту проблему, написав инструменты для явной записи этой информации в ваш репозиторий, но это может быть непросто.

Поиск Google для git резервные метаданные дает ряд результатов, которые, по-видимому, стоит прочитать (включая некоторые инструменты, которые уже пытаются компенсировать проблемы, которые я здесь поднял).

etckeeper был разработан для резервного копирования /etc и решает многие из этих проблем.

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

Хотя технически вы могли бы это сделать, я бы сделал два предостережения против этого:

1. Вы используете систему контроля версий исходного кода для двоичных данных. Поэтому вы используете его для чего-то, для чего он не предназначен.

2, меня беспокоит ваш процесс разработки, если у вас нет процесса (документационного или автоматизированного) для создания новой машины. Что, если вам удастся купить автобус, кто будет знать, что делать и что для вас важно?

Аварийное восстановление важно, однако лучше автоматизировать (сценарий) настройку нового блока разработки, чем просто сделать резервную копию всего. Конечно, используйте git для своего скрипта / документации, но не для каждого файла на компьютере.

Это может быть подходящее решение для резервного копирования, etckeeper основан на этой идее. Но следите за .git права доступа к каталогам, иначе /etc/shadow можно прочитать в .git каталог.

Я использую git как резервную копию своей системы Windows, и это было невероятно полезно. Внизу сообщения я показываю сценарии, которые я использую для настройки в системе Windows. Использование git в качестве резервной копии для любой системы дает 2 больших преимущества:

  1. В отличие от коммерческих решений, которые часто используют собственный закрытый формат, ваша резервная копия находится в формате с открытым исходным кодом, который широко поддерживается и очень хорошо документирован. Это дает вам полный контроль над вашими данными. Очень легко увидеть, какие файлы были изменены и когда. Если вы хотите обрезать свою историю, вы также можете это сделать. Хотите стереть что-то из своей истории? Нет проблем. Получить обратно версию файла так же просто, как и любую команду git.
  2. Столько или мало зеркал, сколько захотите, и для всех можно настроить время резервного копирования. Вы получите свое локальное зеркало, которое не обременено медленным Интернет-трафиком и, таким образом, дает вам (1) возможность делать более частые резервные копии в течение дня и (2) быстрое время восстановления. (Частое резервное копирование - огромный плюс, потому что я считаю, что чаще всего я теряю документ по ошибке пользователя. Например, ваш ребенок случайно перезаписывает документ, над которым он работал последние 5 часов.) Но вы получите свой удаленное зеркало, которое дает преимущество защиты данных в случае локального бедствия или кражи. И предположим, вы хотите, чтобы ваше удаленное зеркало выполняло резервное копирование в определенное время, чтобы сэкономить пропускную способность Интернета? Нет проблем.

Итог: резервное копирование git дает вам невероятные возможности для управления тем, как происходит резервное копирование.

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

Сначала вам нужно установить cygwin (с rsync), а также установить git для Windows: http://git-scm.com/download/win

Затем создайте локальное репозиторий git (запускается только один раз):

init-repo.bat:

@echo off
REM SCRIPT PURPOSE: CREATE YOUR LOCAL GIT-REPO (RUN ONLY ONCE)

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror


REM Create the backup git repo. 
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
mkdir %GBKUP_LOCAL_MIRROR_HOME%
git %GIT_PARAMS% init
git %GIT_PARAMS% config core.autocrlf false
git %GIT_PARAMS% config core.ignorecase false 
git %GIT_PARAMS% config core.fileMode false
git %GIT_PARAMS% config user.email backup@yourComputerName
git %GIT_PARAMS% config user.name backup

REM add a remote to the git repo.  Make sure you have set myRemoteServer in ~/.ssh/config   
REM The path on the remote server will vary.  Our remote server is a Windows machine running cygwin+ssh.  
REM For better security, you could install gitolite on the remote server, and forbid any non-fast-forward merges, and thus stop a malicious user from overwriting your backups.
git %GIT_PARAMS% remote add origin myRemoteServer:/cygdrive/c/backup/yourComputerName.git

REM treat all files as binary; so you don't have to worry about autocrlf changing your line endings
SET ATTRIBUTES_FILE=%GBKUP_LOCAL_MIRROR_HOME%\.git\info\attributes
echo.>> %ATTRIBUTES_FILE% 
echo *.gbkuptest text>> %ATTRIBUTES_FILE% 
echo * binary>> %ATTRIBUTES_FILE% 
REM compression is often a waste of time with binary files
echo * -delta>> %ATTRIBUTES_FILE% 
REM You may need to get rid of windows new lines. We use cygwin's tool
C:\cygwin64\bin\dos2unix %ATTRIBUTES_FILE%

Далее у нас есть оболочка сценария резервного копирования, которая будет регулярно вызываться планировщиком Windows:

gbackup.vbs:

' A simple vbs wrapper to run your bat file in the background
Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "cmd /c C:\opt\gbackup\gbackup.bat"
oShell.Run strArgs, 0, false

Затем у нас есть сам сценарий резервного копирования, который вызывает оболочка:

gbackup.bat:

    @echo off

REM Set where the git repository will be stored
SET GBKUP_LOCAL_MIRROR_HOME=E:\backup\mirror
REM the user which runs the scheduler
SET GBKUP_RUN_AS_USER=yourWindowsUserName
REM exclude file
SET GBKUP_EXCLUDE_FILE=/cygdrive/c/opt/gbackup/exclude-from.txt

SET GBKUP_TMP_GIT_DIR_NAME=git-renamed
for /f "delims=" %%i in ('C:\cygwin64\bin\cygpath %GBKUP_LOCAL_MIRROR_HOME%') do set GBKUP_LOCAL_MIRROR_CYGWIN=%%i

REM rename any .git directories as they were (see below command)
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (%GBKUP_TMP_GIT_DIR_NAME%) do ren "%%i" ".git" 2> nul

SET RSYNC_CMD_BASE=C:\cygwin64\bin\rsync -ahv --progress --delete --exclude-from %GBKUP_EXCLUDE_FILE%

REM rsync all needed directories to local mirror
%RSYNC_CMD_BASE% /cygdrive/c/dev %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/asmith %GBKUP_LOCAL_MIRROR_CYGWIN%
%RSYNC_CMD_BASE% /cygdrive/c/Users/bsmith %GBKUP_LOCAL_MIRROR_CYGWIN%

cacls %GBKUP_LOCAL_MIRROR_HOME% /t /e /p  %GBKUP_RUN_AS_USER%:f

REM rename any .git directories as git will ignore the entire directory, except the main one
for /r %GBKUP_LOCAL_MIRROR_HOME% %%i in (.git) do ren "%%i" "%GBKUP_TMP_GIT_DIR_NAME%" 2> nul
ren %GBKUP_LOCAL_MIRROR_HOME%\%GBKUP_TMP_GIT_DIR_NAME% .git

REM finally commit to git
SET GIT_PARAMS=--git-dir=%GBKUP_LOCAL_MIRROR_HOME%\.git --work-tree=%GBKUP_LOCAL_MIRROR_HOME% 
SET BKUP_LOG_FILE=%TMP%\git-backup.log
SET TO_LOG=1^>^> %BKUP_LOG_FILE% 2^>^&1
echo ===========================BACKUP START=========================== %TO_LOG%
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a%%b)
echo %mydate%_%mytime% %TO_LOG%
echo updating git index, committing, and then pushing to remote %TO_LOG%
REM Caution: The --ignore-errors directive tells git to continue even if it can't access a file.
git %GIT_PARAMS% add -Av --ignore-errors %TO_LOG%
git %GIT_PARAMS% commit -m "backup" %TO_LOG%
git %GIT_PARAMS% push -vv --progress origin master %TO_LOG%
echo ===========================BACKUP END=========================== %TO_LOG%

У нас есть файл exclude-from.txt, куда мы помещаем все файлы, которые нужно игнорировать:

exclude-from.txt:

target/
logs/
AppData/
Downloads/
trash/
temp/
.idea/
.m2/
.IntelliJIdea14/
OLD/
Searches/
Videos/
NTUSER.DAT*
ntuser.dat*

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

Что ж, это неплохая идея, но я думаю, что нужно поднять 2 красных флажка:

  • Если жесткий диск выйдет из строя, вы потеряете все, если не отправите свою фиксацию на другой сервер / диск. (Событие, если у вас есть план, я предпочитаю упомянуть.)

... но тем не менее, это может быть хорошей резервной копией для вещей, связанных с повреждениями. Или, как вы сказали, если папка .git / находится где-то еще.

  • Эта резервная копия всегда будет увеличиваться в размере. По умолчанию нет обрезки, поворота или чего-то еще.

... Таким образом, вам может потребоваться указать вашему cronjob добавить теги, а затем убедиться, что фиксация, которая не помечена, будет очищена.

Я не пробовал его с полной системой, но я использую его для своих резервных копий MySQL (с параметром --skip-extended-insert), и он действительно хорошо сработал для меня.

Вы столкнетесь с проблемой с файлами двоичных данных (все их содержимое может измениться и изменится), и у вас могут возникнуть проблемы с .git папка становится очень большой. Я бы порекомендовал создать .gitignore файл и резервное копирование только тех текстовых файлов, которые действительно вам необходимы.

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

я полагаю rsnapshot быть одним из лучших - если нет то лучше. При хорошем использовании жесткой ссылки у меня есть файловый сервер на 300 ГБ (с полмиллионом файлов) с ежедневным, еженедельным и ежемесячным резервным копированием, насчитывающим один год. Общее используемое дисковое пространство составляет всего одну полную копию + инкрементную часть каждой резервной копии, но благодаря жестким ссылкам у меня есть полный «живая» структура каталогов в каждой из резервных копий. Другими словами, файлы доступны напрямую не только в daily.0 (самая последняя резервная копия), но даже в daily.1 (вчера) или weekly.2 (две недели назад) и так далее.

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

Еще один очень хороший вариант: rdiff-резервное копирование, но поскольку мне нравится, чтобы файлы всегда были доступны, просто указав в Проводнике \\ servername, rsnapshot был для меня лучшим решением.

У меня была такая же идея для резервного копирования с помощью git, в основном потому, что он позволяет создавать резервные копии с поддержкой версий. Потом я увидел rdiff-резервное копирование, который обеспечивает эту функциональность (и многое другое). У него действительно приятный пользовательский интерфейс (посмотрите параметры интерфейса командной строки). Я вполне доволен этим. В --remove-older-than 2W довольно круто. Он позволяет просто удалять версии старше 2 недель. rdiff-backup хранит только различия файлов.

Я очень новичок в git, но по умолчанию ветки не являются локальными и должны быть явно отправлены в удаленные репозитории? Это был неприятный и неожиданный сюрприз. В конце концов, я не хочу все моего локального репо для резервного копирования на сервер? Читая мерзкая книга:

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

Для меня это означало, что эти локальные ветки, как и другие файлы, отличные от git, на моем локальном компьютере, рискуют быть утерянными, если не выполняются регулярные резервные копии какими-либо средствами, отличными от git. Я все равно так делаю, но это нарушило мои предположения о git «резервное копирование всего» в моем репо. Я хотел бы получить разъяснения по этому поводу!

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

Все манифесты конфигурации и установки пакетов хранятся в Puppet, что упрощает повторное развертывание и обновления конфигурации. Каталог Puppet создается с помощью git. Kickstart используется для первоначального развертывания.

Я также храню собственный репозиторий YUM для любых пакетов, которые разрабатываются в то время. Это имеет дополнительное преимущество, заключающееся в том, что любые пакеты, с которыми мы работаем, не остаются в локальной системе как бинарные файлы без присмотра - если это произойдет и файлы будут уничтожены, ну что ж. Кто-то не выполнил надлежащую процедуру.

Вы можете захотеть проверить буп на github который был разработан для использования git для резервного копирования.

Это подход, который используется, он имеет смысл.

Keepconf используйте rsync и git для этой работы, это оболочка над этими инструментами, чтобы упростить задачу.

Вам нужен только центральный сервер с ssh-ключами, настроенными для доступа к резервным серверам, и несколько строк в файле конфигурации. Например, это мой собственный файл для хранения всех установленных пакетов / etc / и debian:

[hosts]
192.168.1.10
192.168.1.11
192.168.1.12

[files]
/etc/*
/var/lib/dpkg/status

При этом у меня есть резервная копия rsync и коммит git.

Лично я считаю, что все это в основном наоборот. Вы помещаете файлы в решение для резервного копирования, а не извлекаете их.

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

Тем не менее, это может сработать, я просто не думаю, что это будет так хорошо.

Попробуйте изучить backuppc - его довольно легко настроить и, честно говоря, он великолепен.

Это могло бы сработать, но два предостережения.

  1. Добавление файлов не будет происходить автоматически при выполнении фиксации. Используйте --porcelean om git status, чтобы найти что-то новое для добавления перед выполнением фиксации.

  2. Зачем нужно удаленное монтирование .ssh? Он может быть хрупким, иначе вы не узнаете, что он потерпел неудачу. Используйте чистый репозиторий для дальнего конца с обычным входом по ssh-ключу. Пока репозиторий пуст и вы нажимаете только из одного источника, он гарантированно будет работать без слияния.

Написал о простом способе сделать это: резервные-орг-файлы в гитхабе

Это работает для файлов, с которыми не ведется совместная работа, в моем случае - файлов emacs org. Я использовал cron для периодического выполнения git commit, git push.