LINUX.ORG.RU
ФорумAdmin

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

 , ,


2

3

Допустим, есть файлопомойка маленькой организации. Малая часть — это plaintext, а остальные — jpg, psd, pdf, doc, xls, ppt, docx, xlsx, pptx, odt, ods, odp, mht, zip, rar, 7z... Дикое месиво из бинарных файлов со сжатием.
Бэкапить имеет смысл только те файлы, которые отличаются. Сначала проверяем чексумму, а потом копируем.
А как лучше хранить несколько разных версий? Есть ли смысл заюзать git? Как его тюнингуют для работы со сжатыми бинарными файлами?

★★★★★

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

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

DALDON ★★★★★ ()

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

invokercd ★★★★ ()
Ответ на: комментарий от blind_oracle

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

deterenkelt ()

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

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

emulek ()

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

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

aol ★★★★★ ()

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

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

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

justAmoment ★★★★★ ()

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

anonymous ()

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

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от invokercd

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

rsync --link-dest

anonymous ()
Ответ на: комментарий от anonymous

rsync --link-dest

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от deterenkelt

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

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

anonymous ()

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

MikeDM ★★★★★ ()
Ответ на: комментарий от anonymous

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

rsync --link-dest

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

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

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

anonymous ()

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

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

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от invokercd

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

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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