Вопрос: GIT как средство резервного копирования


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

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

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

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


87
2017-12-15 12:10


Источник


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


Ответы:


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

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

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

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

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

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


78
2017-12-15 17:25



+1 для упоминания ACL / разрешений - Larry Silverman
Git также не хранит пустые каталоги. - Flimm
и это также отстой для отслеживания перемещения файла / переименования, через историю. - cregox
Поскольку git не очень хорошо разбирается в бинарных файлах, вам также может понадобиться изучить git приложение, что помогает сделать это лучше. Однако он меняет представление о том, что такое git. - Wouter Verhelst
я считаю, что вы можете использовать git для резервного копирования данных, но не для целых серверов - EKanadily


Я не использовал его, но вы можете посмотреть на Информационное агентство Бритиш Юнайтед Пресс который является инструментом резервного копирования на основе git.


20
2017-12-15 13:27



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


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


12
2017-12-15 12:18





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

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

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

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


11
2017-12-15 13:45



Ящики разработки все из файлов KickStart, и на самом деле средний ящик длится около 2 или 3 месяцев, прежде чем он будет перестроен. Но люди меняют конфигурацию и делают что-то, мы перестраиваем коробки, и люди говорят: «Эй, я знаю, что я не поместил ее в исходный контроль, но у меня было какое-то дерьмо в этой коробке», и я смеюсь над ними за то, что они глупы. Все вокруг, хорошие времена. Двоичные данные были бы сукой, это то, что я полностью игнорировал, находясь в душе. - Smudge
Я приветствую ваше отношение к тем, кто не соблюдает основные принципы. Лично у меня есть схожая ситуация с вами, однако у меня есть git-репозиторий, который связывает во всех конфигурационных файлах, которые могут быть важными, а не для всех. Кроме того, dxt с инструкциями. - Phil Hannent
Я думаю, что git отлично работает для двоичных файлов, а основная часть репозитория Google Android - это git-хранилища готовых исполняемых файлов. - user377178


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

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.


6
2018-03-21 17:10



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


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

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

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

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

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


4
2017-12-15 13:40



Вероятно, мы установили каталог .git на удаленном сервере, хотя класический rm -Rf / вызвало бы у нас некоторые проблемы. Наша текущая система резервного копирования хранит материал в течение 2 лет или 50 версий (в зависимости от того, что наступит последним), поэтому наша резервная копия постоянно увеличивается. Но мне нравится идея добавления тегов, у нас могут быть «ежедневные», «еженедельные» и т. Д. Теги - Smudge
+1 для постоянно растущих потребностей в пространстве - hafichuk
@sam git постоянно растет. Вы не можете обрезать историю старше N лет. Я полагаю, что ваша нынешняя система. - rds
Что касается увеличения размера, выполните «git gc» регулярно или перед тем, как нажать на другой (центральный) сервер. Без этого git repo может расти (намного) больше, чем нужно. У меня когда-то было ретрансляцию git объемом 346 МБ, которая может сократиться до 16 МБ. - Hendy Irawan


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

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


3
2017-12-15 13:23



Я использую его для резервного копирования MySQL тоже, с --extended-insert = false. Обязательно «git gc» регулярно или сразу после фиксации. - Hendy Irawan
Видеть Является ли резервное копирование базы данных MySQL в Git хорошей идеей? - Michael Hampton♦


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

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

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

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


3
2018-03-21 20:01



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


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


2
2017-12-15 18:07





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

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

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


2
2018-03-06 13:22



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