Git для бэкапа бинарных файлов?

Question

[pavelpromin]

Хочу посоветоваться по вопросу бэкапа бинарных фалов на основе git.

Исходные данные

• Имеются папки по годам (например 2001, 2002, 2003 и тд)
  
• Размер папки около 3,5Гб каждая
  
• Количество файлов в каждой папке около 14000
  
• Файлы в основном бинарные
  

Требуется

• По окончанию года делать бэкап(коммит) папки года
  
• Делать бэкап(коммит) изменений в папках за другие года если они произошли
  
• Контроль изменений в файле не интересует. Интересует контроль изменения файла в целом.
  

Человечьим языком:

Работаю в папке "2013", но иногда приходится заглядывать в папки 2012 и 2011 в результате чего и там могут произойти изменения.
Год подходит к концу и мне нужно забэкапить папку 2013 как самостоятельную. И так же забэкапить изменения в папках 2012 2011 (например как current).

Как это можно организовать в git? Через создание веток?! Как делать чистые ветки только с текущим годом?!

Comments

[pavelpromin]

Смысл всего этого в инкрементальном резервном копировании данных с их версионированием средствами git.

Answer 1

[Андрей]

По шагам.

1. Делаете чистый репозиторий

2. Делаете ветки для старых годов (git checkout -b 2011)

3. Сохраняете там прежние годы (git add -A && git commit)

4. Возвращаетесь в ветку master (она остается пустой)

5. Делаете следующую ветку (git checkout -b 2012)

6. Повторяем пункт 3

Алсо, во избежание, можно сразу сделать веточку empty, чтобы случайный мердж в master не заставил вас потом делать откаты.

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

Comments

[pavelpromin]

7. Сливаю ветку года с master?! Например, веду я ветку master и делаю коммиты/бэкапы 3-4 раза в год, включая папку 2013. Потом год кончился. Клонирую ветку empty как 2013. Делаю git add 2013. Возвращаюсь в master и продолжаю работать с 2014 Как то так?

[Андрей]

Под каждый год СРАЗУ делаете ветку, в начале года, из empty. И работаете там. Можно конечно и в master вести текущий год, но лучше не надо. И да, перед переключением в другую ветку всегда надо сделать коммит, чтобы файлы, которые не в репе, не побили файлы в другой ветке. Вы совсем немного рассказали, что вам конкретно надо, но есть ощущение, что гит действительно не очень подходит для этого.

[pavelpromin]

Если говорить словами бэкапа, то мне нужно инкрементальное резервное копирование с поддержкой версионности. С подобными вещами не работал (ни с git, ни с backup системами) и поэтому не знаю на сколько оно будет эффективно на практике.

[Андрей]

Ну, гит справится c этим, если все сделать, как я написал. Главное, при переключении веток вам надо делать коммит. Не забывайте об этом, и все будет отлично. Но, да, если файлы бинарные, разрастаться это будет изрядно при каждом коммите, ибо фактически при этом делается копия измененного файла.

Answer 2

[int03e]

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

Answer 3

[Алексей Киселев]

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

mkdir 2014
cd 2014
git init
…
git add .
git commit

При этом ничто не мешает вам работать в репозиториях для прошлых годов и делать там коммиты.

Если нужно сделать копию на другую машину. То клонируем на ней ваши репозитории. Или просто переносим их простым копированием.

Но, если честно, вы придумали очень странное применение Git. Проблема даже не в том, что вы работаете с бинарными файлами, а в том что вы хотите делать коммит раз в год. Это очень очень очень редко.

Comments

[pavelpromin]

В таком варианте получится, что у меня на текущий момент будет 12 репозиториев и это количество будет хоть медленно, но расти. Получается что вместо 2х коммитов (текущего года и изменений за предедущие) их будет более 12. Также проблема в том, что если нужен текущий "срез" мне нужно тянуть из 12 репозироиев. Есть ли другие варианты организации?! В идеале хочется, чтобы изменения велись в одном репозитории. Делаю коммиты несколько раз в год. Потом бац! Конец года - "выделяю" 2013 год в отдельную сущность (как бы замораживаю). Если вдруг понадобится вытащить "замороженную" версию 2013 года - ее легко можно было бы подтянуть без 2012 и тд.

[Алексей Киселев]

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

[pavelpromin]

Бинарные файлы - это DWG. Для DWG, насколько я знаю, нет таких инструментов как GIT для программистов . Проект создается за пару дней и к нему, возможно, никогда больше не обратятся. В год создается несколько сотен проектов. Метка времени важна как для поиска проекта, так и для срока давности. Я ищу плюсы и минусы разных подходов. Здесь есть связка ssh+rsync+git http://habrahabr.ru/post/136313/#comment_4534661

[Алексей Киселев]

Вам нужно смотреть в сторону Document Management Systems. Например, на базе Apache Jackrabbit. В нем есть поддержка версионирования документов. http://www.openkm.com/en/overview/features.html

Answer 4

[Santiago26]

Посмотрите в сторону тегов. Вы можете держать файлы так, как вам удобно, но каждый год - тегировать ревизии номером года. Так в папке 2012 все файлы будут с тегом 2012 и вы их сможете найти по тегу. Если в 2013-ом году вы изменяли файл из папки 2012, то у этого файла будет версия с тегом 2012 и с тегом 2013. И так далее.
Возможно, это стоит совместить с решением kaasius. Также верно, что использование git для бинарных файлов - это нецелевое использование.

Answer 5

[Salt_Of_The_Flame]

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

Comments

[Андрей]

Если есть желание хранить именно версии бинарников - то вполне себе нормальная идея.

[Salt_Of_The_Flame]

уж лучше artifactory или nexus

Answer 6

[zunkree]

Посмотрите http://zbackup.org/.

Answer 7

[Александр]

Как уже сказали, git это не лучшее решение для бекапа или управления бинарными файлами.

Но есть проекты, которые возможно будут вам интересны: git-fat, git-annex, git-media.