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

101

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

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

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

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

мазаться
источник
3
не искрится, используя подобную идею ??
B14D3
@ B14D3 Я думаю, что sparkleshare - это что-то вроде дропбокса, но я посмотрю на это
Smudge
2
вы правы, но он использует git для создания некоторой ошибки (копирование на несколько компьютеров и управление версиями файлов);)
B14D3
Большая проблема в этом состоит в том, что отсутствует центральный контроль - вам необходим прямой (ssh) доступ к машине, чтобы выполнить любую форму обслуживания или проверки резервной копии. Я всегда нахожу, что установка приложения на ящики, для которых необходимо создать резервную копию, а затем администрирование их из центрального местоположения - это гораздо большая победа.
хафичук
@hafichuk С такими инструментами, как Puppet / Chef, это не такая большая проблема, но я понимаю вашу точку зрения.
Пятно

Ответы:

88

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

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

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

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

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

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

larsks
источник
16
+1 за упоминание ACL / разрешений
Ларри Сильверман
23
Git также не хранит пустые каталоги.
Flimm
и это также отстой для отслеживания перемещения / переименования файлов через историю.
cregox
1
Поскольку git не очень хорошо работает с бинарными файлами, вы также можете заглянуть в приложение git , которое поможет сделать это лучше. Однако это несколько меняет представление о том, что такое мерзавец.
Воутер Верхелст
1
Мое мнение
таково,
21

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

тушеное мясо
источник
Никогда не видел bup раньше, выглядит интересно
Smudge
1
Я начал использовать bup недавно, всего за несколько дней до того, как мой жесткий диск вышел из строя;) Восстановление прошло нормально, поэтому рекомендуется!
Андре Парамес
1
@ AndréParamés, то, что вы говорите, это сразу после того, как вы установили, но ваш жесткий диск сломался ... ммммхх ... :) шучу
hofnarwillie
12

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

Камень
источник
11

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

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

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

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

Фил Ханнент
источник
4
Все блоки разработки взяты из файлов KickStart, и на самом деле средний блок длится около 2 или 3 месяцев, прежде чем его перестраивают. Но люди меняют конфиги и делают что-то, мы перестраиваем коробки, и люди говорят: «Эй, я знаю, я не включил это в систему контроля версий, но у меня было немного дерьма на этой коробке», и я смеюсь над ними за глупость. Все вокруг, хорошие времена. Двоичные данные были бы стервой, это то, что я полностью упустил из виду в душе.
Пятно
Я приветствую ваше отношение к тем, кто не следует основным принципам. Лично у меня похожая ситуация с вами, однако у меня есть git-репозиторий, который ссылается на все файлы конфигурации, которые могут быть важны, а не ловить все. Плюс документ TXT с шагами по настройке.
Фил Ханнент
1
Я думаю, что git довольно хорошо работает с бинарными файлами, с другой стороны, большая часть репозитория Google Android - это git-репозитории готовых исполняемых файлов.
user377178 22.12.12
6

Я использую 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.

user64141
источник
Просто любопытно - будет ли он работать и для медленных или нестандартных сетевых дисков, таких как эмулируемые NetDrive или Expandrive? Я считаю, что большинство программ резервного копирования не работает с этими сетевыми дисками. Кроме того, дела идут мучительно медленно и имеют тенденцию к превышению времени ожидания, если я хочу перечислить все файлы в резервной копии и извлечь отдельные файлы. Способен ли git решить эти проблемы?
JustAMartin
@ JustMartin Я никогда не проверял это на сетевых дисках, поэтому не могу сказать. Как только вы получаете файлы в репозитории git, git становится очень эффективным.
user64141
4

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

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

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

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

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

FMaz008
источник
Вероятно, мы бы смонтировали каталог .git на удаленном сервере, хотя rm -Rf /это вызвало бы некоторые проблемы. Наша текущая система резервного копирования хранит информацию в течение 2 лет или 50 версий (в зависимости от того, что наступит позже), поэтому резервное копирование в любом случае постоянно увеличивается. Но мне нравится идея добавления тегов, у нас могут быть теги «ежедневно», «еженедельно» и т. Д.
Smudge
+1 за постоянно растущие потребности в космосе
хафичук
@ Sam Git постоянно растет. Вы не можете обрезать историю старше N лет. Я полагаю, ваша текущая система делает.
выстр
1
Что касается увеличения размера, пожалуйста, делайте 'git gc' регулярно или перед тем, как переходить на другой (центральный) сервер. Без этого git-репо может вырасти (намного) больше, чем должно. Когда-то у меня было 346 МБ git-репо, которое можно сжать до 16 МБ.
Хенди Ираван
3

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

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

Скотт Кек-Уоррен
источник
Я использую его для резервного копирования MySQL, с --extended-insert = false. Обязательно "git gc" регулярно или сразу после коммита.
Хенди Ираван
3

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

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

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

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

shodanshok
источник
Последний выпуск rdiff-backup сделан в 2009 году. Он очень хорошо спроектирован и не требует обновления вообще или это просто заброшенный проект?
Матеуш Конечны,
Я не знаю, поддерживается ли это, но это в основном "сделано".
Шоданшок
Из просмотра savannah.nongnu.org/bugs/… кажется, что в 2015 году была некоторая активность, но многие сообщения об ошибках игнорируются. Я думаю, что я буду классифицировать его как заброшенный.
Матеуш Конечны
2

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

Даниил
источник
2

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

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

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

Мэтью Корнелл
источник
1
Почти все в git, за исключением удаленных, локально. Это по замыслу. Вы можете передавать данные на удаленные устройства, и это следует делать, особенно если используется для резервного копирования, как в этом сценарии. Для ветвей, опять же, да, вам нужно явно нажать их, если вы хотите, чтобы они были добавлены на удаленный. Для разработки это здорово, потому что часто вы хотите что-то протестировать, но нет необходимости сохранять эту ветку тестов бесконечно. Как только вы получите от него то, что вам нужно, вы, вероятно, собираетесь объединить его с веткой dev и удалить ветку test.
LocalPCGuy
1

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

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

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

Тим Бригам
источник
1

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

mcantsin
источник
предыдущий ответ уже указывает на тот же инструмент (bup). serverfault.com/a/341213/303467 . Какие-нибудь основные моменты на этом?
Хавьер
1

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

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.

Rfraile
источник
0

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

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

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

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

Sirex
источник
0

Это будет работать несколько, но две оговорки.

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

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

Андрей
источник