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

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

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

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

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

87 голосов | спросил Smudge 15 ThuEurope/Moscow2011-12-15T16:10:47+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 16:10:47 +0400 2011, 16:10:47

15 ответов


78

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

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

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

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

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

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

ответил larsks 15 ThuEurope/Moscow2011-12-15T21:25:18+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 21:25:18 +0400 2011, 21:25:18
20

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

ответил stew 15 ThuEurope/Moscow2011-12-15T17:27:22+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 17:27:22 +0400 2011, 17:27:22
12

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

ответил Stone 15 ThuEurope/Moscow2011-12-15T16:18:11+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 16:18:11 +0400 2011, 16:18:11
11

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

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

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

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

ответил Phil Hannent 15 ThuEurope/Moscow2011-12-15T17:45:57+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 17:45:57 +0400 2011, 17:45:57
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 [email protected]
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 21 MarpmSat, 21 Mar 2015 20:10:17 +03002015-03-21T20:10:17+03:0008 2015, 20:10:17
4

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

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

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

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

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

ответил FMaz008 15 ThuEurope/Moscow2011-12-15T17:40:10+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 17:40:10 +0400 2011, 17:40:10
3

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

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

ответил Scott Keck-Warren 15 ThuEurope/Moscow2011-12-15T17:23:59+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 17:23:59 +0400 2011, 17:23:59
3

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

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


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

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

ответил shodanshok 21 MarpmSat, 21 Mar 2015 23:01:23 +03002015-03-21T23:01:23+03:0011 2015, 23:01:23
2

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

ответил Daniel 15 ThuEurope/Moscow2011-12-15T22:07:19+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 22:07:19 +0400 2011, 22:07:19
2

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

  

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

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

ответил Matthew Cornell 6 MarpmWed, 06 Mar 2013 17:22:15 +04002013-03-06T17:22:15+04:0005 2013, 17:22:15
1

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

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

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

ответил Tim Brigham 15 ThuEurope/Moscow2011-12-15T18:47:37+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 18:47:37 +0400 2011, 18:47:37
1

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

ответил mcantsin 21 Jam1000000amMon, 21 Jan 2013 10:44:11 +040013 2013, 10:44:11
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 commit.

ответил Rfraile 19 J0000006Europe/Moscow 2015, 11:07:44
0

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

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

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

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

ответил Sirex 15 ThuEurope/Moscow2011-12-15T17:39:04+04:00Europe/Moscow12bEurope/MoscowThu, 15 Dec 2011 17:39:04 +0400 2011, 17:39:04
0

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

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

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

ответил Amoss 6 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 06 Sep 2016 19:30:06 +0300 2016, 19:30:06

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132