Как сделать файловый сервер предприятия с резервным копированием?

[PbI6A]

Доступ - SMB. Количество пользователей порядка 300, объём данных в настоящее время 2Тб, большая перспектива роста. Резервное копирование надо, как минимум, ежедневное, еженедельное, ежемесячное. Если возможно, то и моментальное... Если есть возможность, то ещё чтобы можно было что-то восстановить при порче ФС, а то на вопрос "как вытащить файлы из LVM?" стандартный ответ "бэкап"

[yura_n]

backup-manager может подойти.

[PbI6A]

В настоящее время сделан самособранный кластер, который непрерывно синхронизируетсся с помощью rsync. Резервное копирование делается в режиме обновления архиватором 7z. Период синхронизации ~2 Тб ~1.2 млн файлов rsync-ом порядка 10 минут, цикл резервного копирования порядка 2 часов. Ежедневное, еженедельное и ежемесячное копирование не делается

[zCirill]

Доступ - SMB. Количество пользователей порядка 300, объём данных в настоящее время 2Тб, большая перспектива роста. Резервное копирование надо, как минимум, ежедневное, еженедельное, ежемесячное. Если возможно, то и моментальное... Если есть возможность, то ещё чтобы можно было что-то восстановить при порче ФС, а то на вопрос "как вытащить файлы из LVM?" стандартный ответ "бэкап

Добрый день.
Я так понял нужна постоянная защита ("мгновенное копирование изменений на второй сервер дабы минимизировать потери") и резервирование.

По поводу бэкапирования - в схожем случае очень себя хорошо зарекомендовала rsnapshot, объемы правда там были не 2 ТБ, а 1ТБ, но разницы большой не вижу.
Работает на основе жестких ссылок + ssh + rsync

7 дней, 4 еженедельных, 6 месячных - общий объем занимал порядка 3ТБ, хранится на btrfs с компрессией, поэтому фактически заняло 1.5ТБ
Если страшно про btrfs с компрессией (или zfs) - ну тут ничего не поделать ... хотя все равно, жесткие ссылки рулят, места много не займет.

По опыту применений на файлопомойках rsnapshot (я обычно храню 30 ежедневных копий + архив не удаляемые ежемесячные на другом хранилище) для 30 полных ежедневных копий нужно 160 процентов от занимаемого места.

По поводу "защиты" лучше ее решать в рамках высокой доступности, можно погуглить HA SAMBA
Там уже на вкус и цвет, как реплицируемое хранилище (gluster fs к примеру) или реплика на блочном уровне.

[PbI6A]

В том-то вся и борода, что даже по гигабитной сетке терабайт копируется необозримое в плане восстановления время
Сейчас у меня в серваке 4 винта по 1 Гб, из них сделан софтовый 10 рэйд.
Насчёт "бэкапа от случайного удаления" в виде хардлинков я как-то думал, но потом позабыл. Это прикрутить наверно стоит, слишком много объёма не займёт...
проблема  в другом - мне в принципе перестало нравиться это решение корпоративного файлохранилища в одном месте. Тупо, дебильно звучит, но как пресловутые "все яйца в одной корзине" Уже хочу 10 серверов по 1 Тб и разбросать сетевые диски отделов по 2-3 случайным сервакам с кластерной ФС и динамической заменой и автоматическим заливанием в случае выхода из строя одного нода. Но, думаю, это совсем не просто реализовать

[zCirill]

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

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

распределенное сетевое хранилище с резервированием нод - по дизайну очень похоже на glusterfs. он и CIFS для винды умеет (по крайней мере заявлено)

[PbI6A]

распределенное сетевое хранилище с резервированием нод - по дизайну очень похоже на glusterfs. он и CIFS для винды умеет (по крайней мере заявлено)

В его сторону я посматривал... Вот только не уверен, куда руль повернёт - продолжать мутить с мультитерабайтными объёмами или уже дробить по нескольку шар разных отделов на разные серверы. Уже сейчас я вижу второй вариант более предпочтительным.

[PbI6A]

Нашёл что-то на тему glusterfs: http://www.howtoforge.com/high-availability-storage-with-glusterfs-3.2.x-on-debian-wheezy-automatic-file-replication-mirror-across-two-storage-servers
Буду изучать и пробовать.

[zCirill]

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

таки да, это верный путь.

По дизайну, строение больших файлопомоек очень красиво сделано в DFS (винда)

Есть корень, где перечисляются сервера-хранилища папок. Корни хранятся на столько серверах-сколько хочешь.
Есть папки "хранилища" реплицируемые (на блочном уровне!) на нужное колво серверов.

Все папки для пользователя выглядят как одна шара, при этом на одном сервере могут хранится 2 папки, на другом 1, на втором все 3.
Учитывая сжатие на уровне NTFS - мега красота. Не без глюков и стучания головой об стол, но работает.

На glusterfs можно сделать сходную схему, но там есть нюансы с Replicate массивами, я уже по длительности времени не помню.

[PbI6A]

Взялся копать clusterfs. Замороченная штука, огромное количество виртуальных прослоек. Ставится glusterfs-server, который поднимает тома (volume) на избранных нодах. К кластеру цепляется glusterfs-client, который через fuse отображает содержимое кластерных томов в локальную фс. Эта локальная фс расшаривается через smb пользователям. Как-то так
Сообщение объединено: 06 ноября 2013, 10:53:28
...плюс ко всему, она не работает Тупо виснет при попытке подключения клиентом.

[zCirill]

вы случаем не копировали виртуалку для тестов?
я как раз с glusterfs напоролся на одинаковые uuid в чем то там, с тех пор виртуалки все разворачиваю автоинсталом.

ну и логи надо смотреть, ессно.

[PbI6A]

Ещё немного насчёт DFS и дифирамбов в сторону винды... Идея DFS хорошая, а реализация оказалась странная. Ушли от нее лет 5 назад. Из-за того, что никто не может гарантировать, что обращаясь к некоему файлу на некоем сетевом диске это не вызовет вполне конкретных сетевых коллизий. Реально, пара человек открывает один и тот же файл, редактирует, сохраняет, а админ потом должен разгребать и нести ответственность, почему человек пол дня работал и не осталось ничего... Да и время синхронизации оставляло желать лучшего. Я не помню, какой объём данных был тогда (сейчас ~1.7Тб), но синхронизация не происходила часами! Человек кидает документ на сетевой диск, говорит другому забрать, а его нет и нет... Часами нет! У меня циклический rsync синхронизирует 1.7Тб примерно за 5-10 мин, разумеется, если не было глобальных подвижек инфы.

Короче, переделал я бэкапный скрипт http://sashakrasnoyarsk.tk/?p=1049 и думаю что наверно пока так оставлю. Только на обеих нодах хочу извести Убунту. Одну уже на Дебиан переставил. И уберу выборы в нодах, одна будет всегда главная, а если вдруг упадёт, то поднимать или перенастраивать руками будем.

[PbI6A]

Пичалько...
7z a $bk_to/$name.7z -ms=on -ssc -mx=5 -w$bk_to/ -y -x\@$excl_file $tmp_path/*>$bk_to/$name.log
бэкапит данные так, что при каждом бэкапе архив растёт в объёме на размер полного бэкапа Что-то я не правильно делаю?

[zCirill]

Из-за того, что никто не может гарантировать, что обращаясь к некоему файлу на некоем сетевом диске это не вызовет вполне конкретных сетевых коллизий. Реально, пара человек открывает один и тот же файл, редактирует, сохраняет, а админ потом должен разгребать и нести ответственность, почему человек пол дня работал и не осталось ничего... Да и время синхронизации оставляло желать лучшего. Я не помню, какой объём данных был тогда (сейчас ~1.7Тб), но синхронизация не происходила часами!

DFS не без проблем, факт. пришлось мне с ней повоевать как то.

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



Сообщение объединено: 20 ноября 2013, 19:06:13

Пичалько...
7z a $bk_to/$name.7z -ms=on -ssc -mx=5 -w$bk_to/ -y -x\@$excl_file $tmp_path/*>$bk_to/$name.log
бэкапит данные так, что при каждом бэкапе архив растёт в объёме на размер полного бэкапа  Что-то я не правильно делаю?

Не используете rsnapshot и сжатие на уровне fs )
Не зачем тратить процессорное время на сжатие-расжатие в случае восстановления. Не зачем тратить свое время на поиск по архивам нужных файлов.

Я сколько не возился с упакованными бэкапами - сплошное огорчение и потря времени на внимание. То место для временных файлов закончится, то распаковать места нет. А как просто найти файл в архивах, если пользователь только примерно помнит название файла и примерную дату?
В случае rsnapshot cмапил пользователю директорию - и давай, ройся сам ))

[PbI6A]

Если я правильно понял описалово, rsnapshot делает в директории "бэкапа" полную копию всей резервируемой инфы в виде директорий и хардлинков? Если какой-то файл удаляется, то всё ок, а если перезаписывается? Или, того хуже, дописывается >>в конец? В этом случае изменится и файл во всех директориях "бэкапа" Или я не прав?

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

Надо разжиться ещё несколькими 1Tb винтами, расширить sw raid10 с 4 до 6 винтов и попробовать замутить на 2-м серваке.