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 backup дает ряд результатов, которые, по-видимому, стоит прочитать (включая некоторые инструменты, которые уже пытаются компенсировать проблемы, которые я здесь поднял).

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

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

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

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

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

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

Аварийное восстановление важно, однако лучше автоматизировать (создать сценарий) настройку нового блока разработки, чем просто сделать резервную копию всего. Обязательно используйте 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, в который мы помещаем все игнорируемые файлы:

исключить-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файл и выполнять резервное копирование только тех текстовых файлов, которые вам действительно нужны.

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

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

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

Другим очень хорошим вариантом является rdiff-backup , но так как мне нравится, чтобы файлы всегда были доступны, просто отправив Explorer в \\ имя_сервера, rsnapshot стал для меня лучшим решением.

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

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

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

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

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

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

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

Возможно, вы захотите проверить bup на 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? Это может быть хрупким Bd, вы не будете знать, что это не удалось. Используйте пустой репозиторий для дальнего конца с обычным логином ssh-ключа. Пока репозиторий пуст и вы используете только один источник, он гарантированно будет работать без слияния.