Использование 7zip для бэкапа данных. Продолжение

[zepps]

Хотели тоже использовать 7zip для бэкапа файлового сервера, но отказались из-за того что он не копирует права доступа к файлам.

[RuslanT]

В таких случаях обычно делают tar, который затем зажимают 7zip'ом. Тогда права доступа сохраняются.

[zepps]

А разве tar умеет сохранять права для доступа NTFS?

[an0n1m0us]

да, если они замаплены в xattrs

[dymdym]

как у вас все сложно

[sunnybear]

7z из-под WSH из-под ActiveX из-под IE тормозит. Возможно, в данном случае это не критично.

P.S. ту же методику используем для сборки пакетов приложения

[Scrill]

Думаю было бы проще мигрировать на Active Directory :))

[naryl]

Почитал только до хабраката, :) но rsync вроде всем требованиям легко удовлетворяет.
Вот хорошая статья. www.mikerubel.org/computers/rsync_snapshots/

[Iv8]

А еще точнее rsnapshot.

Инкрементальные копии с указанием интервалов и продолжительности хранения…

[Constantin]

А что, если не секрет, вынудило вас делать бэкапы средствами клиентов, а не средствами сервера и тем самым так все усложнять?

[sdm]

До конца не читал, думаю, что действительно велосипед, для бэкапов для себя выбрал три открытых и бесплатных системы:

для unixlike систем: ribs (Rsync incremental backup script) — freshmeat.net/projects/ribs/
где требуется интерфейс: BackupPC — backuppc.sourceforge.net/

для windows: Cobian Backup — http://www.educ.umu.se/~cobian/cobianbackup.htm

[sdm]

Интерес взял верх, прочитал таки какую-то часть, увидел Cobian Backup, и причину почему онный не подходит, потому извиняюсь, в любом случае приведенные выше ссылки могут кому-то пригодиться.

[den_rad]

Спасибо за Cobian Backup, хорошая программа. Буду настраивать бекапы в своей сети с помощью нее.

[ColorFlow]

как все сложно…

[stas_agarkov]

7z и бекапы несовместимы
я один раз делал им бекап, а он не засунул в бекап базу mysql (ibdata1), потому что не смог ее эксклюзивно открыть для чтения (база в это время работала, но запросов на изменение на нее не шло)
так я потерял базу. потому что подумал, что она есть в бекапе и отформатировал винт.
он конечно показал длинный список файлов, который не удалось добавить в архив, но ведь кто его читает?

[non7top]

админы читают и обрабатывают коды завершения. если он не 0 то бэкап в любом случае фейлиный и пинать на софт который работает правильно не стоит.

[stas_agarkov]

да в gui интерфейсе под виндой это делал перед переустановкой винды :)

[non7top]

ну кто же тебе виноват что ты несообразительный студент и делаешь _бэкапы_ _важной_ базы через хренпоймиколено

[demmsnt]

У меня похожая проблема. Но отличие кардинальное, у меня все важные данные уже на сервере. В итоге получаем полтора террабайта данных. Раньше зеркалировал с помощью Unison. Теперь ручками делаю.

проблема примерно следующего характера — такой большой обьем не успевает скопироваться за ночь. Выделять «вот это копируем: а вот это нет» не хочется именно потому, что какраз то, что не копировали и понадобится.

На данный момент есть недоделанный проект скрипта резервного копирования. Стратегия копирования такая:

1) Всетаки разбиваю копию на «Почта, БД, Приложения»
2) Копирование начинается в 22 и идет до 6. Если в процессе копирования к 6 утра, скажем БД скопировалось на 80%, то копирование оста на следующий день эти 80% будут уничтожены и процесс начнется с с БД. И так потихоньку.

Почему нельзя копировать во время работы? Представтье вы уже скопировали справочник товаров и начали копировать журнал документов. В этот момент в справочник товаров попадет новый товар и в конец журнала документов попадет запись с ЭТИМ товаром. Но при восстановлении такая база бесполезна!

Какие еще загвоздки есть? Например права пользователя. Как тут предложили tar+bz2. Но вы пробовали распаковать 800Gb tgz из-за одного файла? Поэтому я делаю bz2+tar + текстовый файл с первоначальными именами. Тоесть каждый файл сжимаю, а потом пихаю в tar.

Далее я разделил процесс сжатия и получения списка файлов, а всю информацию храню в SQLite чтоб искать когда что поменялось.

Очень хочется дописать эту систему и запустить, но нет времени.