LINUX.ORG.RU
ФорумAdmin

Content tracking для /, но без идиотизма

 ,


1

2

Некоторое время пытаюсь применять git для отслеживания изменений в файлах на системе (VPS на Gentoo).

Возможности, ради которых я пошёл на такой изврат:

  • git status, git diff удобно покажут, что я изменил в процессе редактирования настроек с момента создания предыдущей контрольной точки (коммита) - контроллируем отсутствие случайных изменений;
  • git status покажет, какие именно файлы изменены в процессе emerge, dispatch-conf;
  • тот же git status покажет, какие спонтанные изменения происходят в системе помимо прямых действий администратора;
  • шаги изменения настроек или установки новых пакетов можно и нужно аннотировать (в commit message);
  • удобно найти в истории и просмотреть содержание конкретного изменения - может помочь вспомнить при настройке других систем, что именно следует менять, и в какой последовательности настраивать и устанавливать пакеты;
  • если коммитить аккуратно и гранулированно, то лог коммитов является готовым руководством по совершению аналогичных инсталляций.
  • можно легко откатываться на последнюю или предыдущие контрольные точки через git reset --hard.

Но, увы, есть серьёзные недостатки:

  • при появлении новых файлов нужно делать «git add». Если это результаты emerge - то как минимум «git add .» (cwd=/), плюс нюансы (см. ниже);
  • некоторые файлы и каталоги вводить под отслеживание git-ом нецелесообразно, в результате имеем большой файл .gitignore, который по ходу эксплуатации необходимо поддерживать в актуальном состоянии, а также удалять ранее попавшие файлы подобного рода из старых коммитов с помощью git-filter-branch (с которым вообще мозг сломаешь, тем более, что нужен он редко);
  • в силу того, что определённые файлы, находящиеся в системе, мы в git не храним, а также потому, что git не хранит инфу о владельце, и, возможно, ещё по массе причин, результирующий репозиторий НЕ ЯВЛЯЕТСЯ ПОЛНОЦЕННЫМ БЭКАПОМ, при этом
  • занимаемый объём под .git ощутим.

Итак - есть ли системы бэкапа, обладающие плюсами описанного способа, и не имеющие данных минусов? Иными словами, с возможностями:

  • аннотирования инкрементальных бекапов (git commit -m);
  • запуска создания инкрементального бэкапа командой с бэкапируемой системы, с заданием аннтоации;
  • пометить инкрементальный бэкап как вечно хранимый, а также с вечным хранением всех аннотаций (для получения «записок склерозника»);
  • увидеть содержимое инкрементального бэкапа, примерно в виде diff;
  • аналогичными git status/git diff, доступными для запуска на бэкапируемой машине.

P. S. С серьёзными решениями для бэкапа не знаком, данные на практике резервирую дублированием с помощью rsync или git.

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

Deleted ()

git|etckeeper - git for /etc - that's make sense

anonymous ()

ZFS. правда я хз как там, дошло ли дело до реализации diff и send/receive на линуксе, в отличии от «загнивающей» проприетарщины.

anonymous ()

некоторые файлы и каталоги вводить под отслеживание git-ом нецелесообразно

/usr/bin/*, /usr/lib/* и т.д.?

занимаемый объём под .git ощутим

Он плохо разруливает бинарные файлы. По-моему, вообще никак.

$ mkdir /tmp/test-repo && cd /tmp/test-repo
$ git init
Initialized empty Git repository in /tmp/test-repo/.git/
$ dd if=/dev/urandom of=test-file bs=10M count=1
1+0 records in
1+0 records out
10485760 bytes (10 MB) copied, 3.5481 s, 3.0 MB/s
$ git add test-file
$ git commit -m 'Initial commit'
[master (root-commit) e0352f8] Initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test-file
$ du -sh .git
11M	.git
$ echo "1" >> test-file
$ git commit -a -m 'Added one symbol'
[master c100bc2] Added one symbol
 1 file changed, 0 insertions(+), 0 deletions(-)
$ du -sh .git
21M	.git
Так что лучше там хранить только /etc.
Я уже выкладывал тут скриптик, которым делает версионированный бэкап через rsync. commit message можешь положить рядышком в текстовый файл.
+ Дополнительное место занимают только измененные файлы, остальные сохраняются по hardlink.
+- Лучше использовать reiserfs, в ней нет ограничений на количество ссылок.
http://pastebin.com/behtPyKj (c) inspired by http://habrahabr.ru/post/149059/

git status, git diff

В этом случае не так удобно, и совсем не быстро, но diff -rq /source /path/to/backup

можно легко откатываться на последнюю или предыдущие контрольные точки через git reset --hard.

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

getup ()
Последнее исправление: getup (всего исправлений: 3)
Ответ на: комментарий от getup

некоторые файлы и каталоги вводить под отслеживание git-ом нецелесообразно

/usr/bin/*, /usr/lib/* и т.д.?

 # cat .gitignore 
/bkp/
/dev/
/etc/ld.so.cache
/etc/config-archive
/mnt/
/proc/
/sys/
/root/
/home/
/tmp/
/usr/portage/
/usr/share/doc/
/usr/share/man/
/usr/src/
/usr/local/src/
/var/cache/                                                                                                                                                                                   
/var/tmp/                                                                                                                                                                                     
/var/www/                                                                                                                                                                                     
/var/spool/                                                                                                                                                                                   
/var/lib/mysql/                                                                                                                                                                               
/var/lib/mlocate/mlocate.db                                                                                                                                                                   
/var/lib/asterisk/astdb                                                                                                                                                                       
/var/lib/asterisk/sounds/recorded                                                                                                                                                             
/var/lib/misc/random-seed                                                                                                                                                                     
/lib64/rc/init.d/
/lib64/rc/cache/
/var/log/
/var/run/
/run/
.asterisk_history
*__pycache__*

http://pastebin.com/behtPyKj (c) inspired by http://habrahabr.ru/post/149059/

Статья отличная! Разумно использована фича hardlink, я бы не догадался. И не думал, что на основе rsync легко получится делать подобные инкрементные бэкапы.

Очень вам благодарен. Это решение и буду применять.

Krieger_Od ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.