Бэкап и контроль версий для организации

А как лучше хранить несколько разных версий? Есть ли смысл заюзать git?

Для именно твоего случая идеально подойдёт rdiff-backup. Чуть более жирнее, но более быстрее будет rsnapshot.

Объёмы какие? В принципе гит прокатит, скорее всего.

rdiff-backup или можно duplicity как более прокачанный, я думаю поудобнее гита и место сэкономит хоть немного.

С гитом будет удобней, но он быстро разжиреет и станет неповоротлив, я гарантирую это. Это будет rebase и чистка каждую неделю. Проще уж бекапать всю файлопомойку на отдельный жестак. Можно ещё поставить перед руководством вопрос о покупке стримера.

diff _не_ даст результатов. Т.ч. придётся держать _все_ версии файла. В принципе git можно использовать для хранения и синхронизации _имён_ файлов с меткой версии. А вот сами файлы — увы, пусть так лежат.

Т.е. git будет хранить файл(ы), в котором каждая строчка — имя(внутреннее, например md5) какого-то XXX.DOC. Что-бы закоммитить ревизию тебе нужно залить файлы, сделать новый список, и коммит. В другом списке надо хранить соответствие имён и внутреннего имени.

Так как про помойку ты ничего не сказал, я предлагаю тебе модуль для самбы. Называется previous versions. Клиент код венду качается с сайта офтопика. Выбор версии на клиенте происходит в стандартном диалоге свойств файла (там появляется ещё одна вкладка).

Ну, а бэкапить - как обычно.

Попробуй вот так.

1. Архивный сервер на btrfs.
2. Копируем всё целиком на архивный сервер при помощи rsync.
3. Делаем снапшот btrfs. Именуем его сегодняшним числом.
4. Проходят сутки.
5. Копируем все изменения на архивный сервер при помощи rsync.
6. Делаем снапшот btrfs. Именуем его сегодняшним числом.
7. GOTO 4

При необходимости монтируется снапшот за нужное число и достаются нужные файлы. Ненужные/устаревшие/неудачные снапшоты удаляются.

Я дома бэкаплю на снапшоты в zfs - семь ежедневных, четыре недельных и один месячный. Все это парой простых скриптов на 5 строчек. Если надо могу скинуть. Вполне себе версионность :)

Кстати, есть ли лаги по скорости после снимков? Какая версия модуля?

Если надо могу скинуть.

есть просьба выложить скрипт здесь.

Кроме бэкапа полезно сделать ещё две вещи:

Поискать дубликаты: fslint и fdupes.

Поискать большие ненужные файлы: gdmap, kdirstat и ncdu.

git не умеет удалять старые версии, а диск не резиновый.

Диск с зфс бэкапный, я на него делаю rsync и потом там снапшот и клон, так что по скорости ничего не скажу. Модуль 0.6.3 вроде.

Диск с зфс бэкапный, я на него делаю rsync и потом там снапшот и клон

Зачем такие сложности?

rsync --link-dest

rsync --link-dest

Затем, что у меня файлы на одном массиве, а бэкап - на другом диске. Хардлинки, соответственно, между разными ФС не работают.

С гитом будет удобней

Даже если в файлопомойке у кого-то гит?

купи большие винты, и сделай нормальную ротацию.

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

rsync --link-dest

Затем, что у меня файлы на одном массиве, а бэкап - на другом диске. Хардлинки, соответственно, между разными ФС не работают.

Хардлинк на оригинал - это вообще не бэкап, они меняются одновременно. Речь про хардлинки между снапшотами бэкапа.

http://www.mikerubel.org/computers/rsync_snapshots/

Можно опробовать ZFS, снапшоты весят мало, делаются быстро. Ну и вытащить старую копию достаточно просто и тоже быстро.

Update: проглядел, ZFS уже посоветовали

Кстати, есть ли лаги по скорости после снимков?

В интернетах пишут, что проблемы с томом(не пулом, именно томом) начинаются от тысячи снапшотов на нём

Речь про хардлинки между снапшотами бэкапа.

Да, я понял, но снапшоты эффективнее. Часть файла изменил - только часть файла клонировалась.