GIT як резервний інструмент


101

На сервері встановіть git

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

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

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


3
не блискавично використовуючи подібну ідею ??
B14D3

@ B14D3 Я думаю, що sparkleshare - це щось подібне до типу "Dropbox", але я роздивлюся це
Smudge

2
Ви маєте рацію, але це за допомогою git, щоб зробити якусь штучку з копіювання (копіювання на декілька ПК та керування версіями файлів);)
B14D3

Велика проблема з цим полягає в тому, що немає централізованого управління - вам потрібно мати прямий (ssh) доступ до машини, щоб підготувати будь-яку форму обслуговування або резервної перевірки. Я завжди вважаю, що встановити додаток на резервні копії, а потім керувати ними з центрального місця - це набагато більший виграш.
hafichuk

@hafichuk З такими інструментами, як Ляльковий / шеф-кухар це не така велика проблема, але я бачу вашу думку.
Мазок

Відповіді:


88

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

Найбільша проблема використання gitрезервного копіювання полягає в тому, що він не зберігає більшість метаданих файлової системи. Зокрема, gitне записує:

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

Ви можете вирішити це, написавши інструменти для явного запису цієї інформації у ваше сховище, але це може бути складним, щоб отримати це право.

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

etckeeper був розроблений для резервного копіювання /etcта вирішує багато з цих проблем.


15
+1 за згадування ACL / дозволів
Ларрі Сільверман

22
Git також не зберігає порожні каталоги.
Flimm

і він також підходить для відстеження переміщення / перейменування файлів через історію.
Крегокс

1
Оскільки git не дуже добре справляється з бінарними файлами, ви також можете заглянути в додаток до git , що допомагає зробити це краще. Однак це дещо змінює уявлення про те, що git дещо.
Wouter Verhelst

1
на мою думку, ви можете використовувати git для резервного копіювання даних, але не на всіх серверах
EKanadily

21

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


Ніколи раніше не бачив гру, виглядає цікаво
Мазок

1
Я почав використовувати bup нещодавно, лише за кілька днів до того, як мій жорсткий диск вийшов з ладу;) Відновлення пройшло нормально, тому рекомендується!
Андре Парамеш

1
@ AndréParamés так , що ви говорите, тільки після того, як ви встановили БУП жорсткий диск розбився ... mmmmhh ... :) жартую
hofnarwillie

12

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


11

Хоча технічно це можна зробити, я би поставив проти нього два застереження:

1, Ви використовуєте систему управління версіями джерел для двійкових даних. Тому ви використовуєте його для чогось, для чого він не був розроблений.

2, я хвилююся щодо вашого процесу розробки, якщо у вас немає процесу (документації або автоматизованого) для створення нової машини. Що робити, якщо вам вдалося придбати автобус, який би знав, що робити і що важливо?

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


4
Усі вікна розробки походять з файлів KickStart, і насправді середнє поле триває приблизно 2 або 3 місяці до його відновлення. Але люди міняють конфігурації і роблять речі, ми відновлюємо коробки, і люди кажуть "ей, я знаю, що я не поставив це під контроль джерела, але у мене було якесь лайно в цьому полі", і я сміюся з них за те, що вони дурні. Все навколо, добрі часи. Бінарні дані були би сукою, це те, що я повністю занедбав, перебуваючи під душем.
Мазок

Я схвалюю ваше ставлення до тих, хто не дотримується основних принципів. Особисто я маю схожу ситуацію з вами, однак у мене є сховище git, яке посилається на всі файли конфігурацій, які можуть бути важливішими, а не спітком усіх. Плюс txt doc з кроками налаштування.
Філ Ханнент

1
Я думаю, що git працює досить добре для бінарних файлів, але основна частина репо-файлів Google Android є репозиторіями git попередньо вбудованих виконуваних файлів.
користувач377178

6

Я використовую git як резервну копію для своєї системи Windows, і це було надзвичайно корисно. У нижній частині публікації я показую сценарії, які використовую для налаштування в системі Windows. Використання git як резервного копіювання для будь-якої системи забезпечує 2 великі переваги:

  1. На відміну від комерційних рішень часто використовують власний фірмовий формат, ваша резервна копія знаходиться у форматі з відкритим кодом, який широко підтримується і дуже добре задокументований. Це дає вам повний контроль над своїми даними. Дуже легко зрозуміти, які файли змінилися і коли. Якщо ви хочете обрізати свою історію, ви також можете це зробити. Хочете видалити щось із своєї історії? Нема проблем. Повернення версії файлу назад так само просто, як і будь-яка команда git.
  2. Стільки дзеркал, скільки ви хочете, і всі можуть настроювати час резервного копіювання. Ви отримаєте своє місцеве дзеркало, яке не обтяжене повільним інтернет-трафіком, і таким чином дає вам (1) можливість робити частіші резервні копії протягом дня та (2) швидкий час відновлення. (Часті резервні копії - це величезний плюс, тому що я вважаю, що найбільше часу втрачаю документ - це помилка користувача. Наприклад, ваша дитина випадково перезаписав документ, над яким працював останні 5 годин.) Але ви отримаєте свій віддалене дзеркало, яке дає перевагу захисту даних у разі локальної катастрофи або крадіжки. І припустимо, ви хочете створити резервну копію віддаленого дзеркала в індивідуальний час, щоб зберегти Інтернет-пропускну здатність? Нема проблем.

Підсумок: Резервне копіювання git дає вам неймовірні можливості контролювати, як відбуваються ваші резервні копії.

Я налаштував це в своїй системі Windows. Перший крок - створити локальну git repo, де ви будете вносити всі свої локальні дані. Я рекомендую використовувати локальний другий жорсткий диск, але використовувати той же жорсткий диск буде працювати (але, як очікується, ви натиснете це кудись віддалено, або інакше ваш гвинт, якщо жорсткий диск помре.)

Спочатку потрібно встановити cygwin (з rsync), а також встановити git для Windows: http://git-scm.com/download/win

Далі створіть локальне git repo (запускається лише один раз):

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%

У нас є файл виключення-from.txt, де ми ставимо всі файли для ігнорування:

виключити-з.txt:

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

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


Цікаво - чи буде це працювати і для повільних або нестандартних мережевих накопичувачів, як-от ті, що емулюються NetDrive або Expandrive? Я вважаю, що більшість програмного забезпечення для резервного копіювання не працює з цими мережевими накопичувачами. Крім того, справи стають болісно повільними і мають тенденцію до тайм-ауту, якщо я хочу перелічити всі файли в резервній копії та витягнути окремі файли. Чи здатний git вирішити ці питання?
JustAMartin

@JustAMartin Я ніколи не тестував це на мережевих накопичувачах, тому не можу сказати. Як тільки ви отримуєте файли в git repo, git стає дуже ефективним.
user64141

4

Ну це не погана ідея, але я думаю, що потрібно підняти 2 червоні прапори:

  • Якщо жорсткий диск вийде з ладу, ви втратите все, якщо не підштовхуєте свою комісію до іншого сервера / диска. (Подія, якщо у вас є план на це, я вважаю за краще згадати.)

... але все-таки це може бути гарним резервом для речей, пов’язаних з корупцією. Або, як ви сказали, якщо .git / папка десь в іншому місці.

  • Ця резервна копія завжди збільшуватиметься в розмірах. За замовчуванням немає обрізки чи обертання чи нічого.

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


Ми, мабуть, змонтуємо каталог .git на віддаленому сервері, хоча класичність rm -Rf /спричинить у нас деякі проблеми. Наша теперішня система резервного копіювання зберігає інформацію протягом 2 років або 50 версій (залежно від того, що сталося останнім), тому наша резервна копія все одно постійно збільшується. Але мені подобається ідея додавання тегів, у нас могли бути теги "щоденно", "щотижня" тощо
Smudge

+1 за постійно зростаючих потреб у космосі
гафічук

@sam git постійно зростає. Ви можете підрізати історію старше N років. Я вважаю, що ваша нинішня система це робить.
rds

1
Щодо збільшення розміру, будь ласка, робіть "git gc" регулярно або перед тим, як перейти на інший (центральний) сервер. Без цього git repo може зрости (набагато) більшим, ніж повинен. Я колись мав 346 Мб git repo, який може скоротитися до 16 Мб.
Хенді Іраван

3

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

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


Я також використовую його для резервного копіювання MySQL, з --extended-insert = false. Обов’язково регулярно або відразу після фіксації "git gc".
Хенді Іраван


3

Я колись розробив резервне рішення на основі підриву. Хоча це працювало досить добре (і git повинен працювати ще краще), я думаю, що тут є кращі рішення.

Я вважаю rsnapshot бути один з найкращих - якщо не краще. При доброму використанні жорсткого посилання я маю сервер файлів об'ємом 300 ГБ (з півмільйона файлів) з щоденними, щотижневими та щомісячними резервними копіями, що повертаються на протязі одного року. Загальний використаний простір на диску - це лише одна повна копія + додаткова частина кожної резервної копії, але завдяки жорстким посиланням у мене є повна структура "живої" каталогів у кожній із резервних копій. Іншими словами, файли безпосередньо доступні не лише у щоденному режимі.0 (найновіша резервна копія), але навіть у щоденній 1 (вівторок) або щотижневий 2 (два тижні тому) тощо.

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

Ще один дуже хороший варіант - rdiff-резервне копіювання , але, як мені подобається, щоб файли завжди були доступні просто за допомогою курсора Explorer на \\ ім’я сервера, rsnapshot був кращим рішенням для мене.


Останній випуск rdiff-резервного копіювання - з 2009 року. Це надзвичайно добре розроблений і не потребує оновлення взагалі або це просто занедбаний проект?
Матеуш Конічний

Я не знаю, чи це вдома, але це в основному "зроблено".
shodanshok

З огляду на savannah.nongnu.org/bugs/…, здається, що деяка активність була ще в 2015 році, але багато звітів про помилки ігноруються. Я думаю, що класифікую це як занедбане.
Матеуш Конічний

2

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


2

Я надзвичайно новачка в git, але чи не гілки локальні за замовчуванням, і їх потрібно явно пересувати у віддалені сховища? Це було неприємним і несподіваним сюрпризом. Зрештою, я не хочу, щоб усі мої локальні репо були "резервними копіями" на сервері? Читання книги з git :

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

Для мене це означало, що ті локальні гілки, як і інші нежиткові файли на моїй локальній машині, ризикують бути втраченими, якщо регулярно не створювати резервні копії якимись засобами, що не містять git. Я все одно це роблю, але це порушило мої припущення щодо git "резервного копіювання всього" в моїй репо. Я хотів би роз'яснення з цього приводу!


1
Практично все, що стосується git, за винятком дистанційних, - місцеве. Це за дизайном. Ви можете підштовхувати речі до віддалених, і, особливо, якщо вони використовуються для резервного копіювання, як у цьому сценарії. Знову ж, для гілок, так, вам потрібно явно натиснути їх, якщо ви хочете, щоб вони були додані до пульта. Для розвитку це чудово, тому що часто потрібно щось тестувати, але немає необхідності зберігати цю тестову гілку на невизначений термін. Як тільки у вас з’явиться те, що вам потрібно від нього, ви, швидше за все, збираєтесь об'єднати його в гілку розробок і поділити тестову гілку.
LocalPCGuy

1

Я вважав, що це хороша методологія для моїх розробників. Це змінює їх на те, що потрібно створити резервну копію лише до кінцевої точки розгортання.

Усі маніфести конфігурації та встановлення пакунків зберігаються в Puppet, що дозволяє легко перевстановити та оновити конфігурацію. Каталог ляльок створений із резервної копії git. Kickstart використовується для початкового розгортання.

Я також зберігаю спеціальний сховище YUM для будь-яких пакунків, що розробляються в той час. Це має додаткову перевагу в тому, що будь-які пакунки, з якими ми працюємо, не залишаються лише бінарними файлами без нагляду в локальній системі - якщо це станеться, і файли стануть нукірованими. Хтось не дотримувався належної процедури.


1

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


попередня відповідь вже вказує на той самий інструмент (буп). 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.


0

Моя особиста думка полягає в тому, що це в основному все назад. Ви натискаєте файли на резервне рішення, а не витягуєте їх.

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

Це сказало, що це може спрацювати, я просто не думаю, що це було б так добре.

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


0

Це працювало б дещо, але два застереження.

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

  2. Чому неприємності віддаленого кріплення для .ssh? Це може бути тендітним Bd, ви не знатимете, що це не вдалося. Використовуйте голий сховище для дальнього кінця із звичайним входом ключа ssh. Поки сховище оголене, і ви натискаєте лише з одного джерела, це гарантовано працює без злиття.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.