Задача: обеспечить инкрементальный бэкап данных общим объемом около 600-700 гб, с очень маленькими промежутками по времени, например, раз в 2 часа. Хранить — неделю.
Данные представляют из себя кипу относительно мелких файлов, вроде doc, xls и разнообразных картинок. Изменяются практически постоянно, двумя-тремя десятками пользователей. Цель — обеспечить защиту от случайной потери данных, весьма часто возникающей по причине криволапости пользователей.
Весь объем (при необходимости) можно разнести на три части — две по ~300 гб и одну - остатки.Держать все предполагается на полусофтварном или полностью софтварном Raid5, общим объемом 1,8 тб (возможности поставить приличный рейд в ближайшее время не предвидется, но есть в планах).
Предпочтительная ОС — FreeBSD 7.0. Другие варианты рассматриваются со скрипом, в виду неуживчивости контроллера рейда.
Доп. условия: виндовый домен, т. е. на сервере будет samba.Внимание, вопрос!
Как бы это поэффективнее реализовать?Склоняюсь в сторону снапшотов, но не знаю, средствами чего. UFS от такого количества умирает, LVM — не дружит с FreeBSD. ZFS?
Другие варианты так же принимаются с радостными воплями!
Очень надеюсь на помощь.
Навскидку могу предложить 2 варианта:1. Серьезный. Bacula, которая все делает на локальных хранилищах, вместо лент. Плюсы: легко переехать на ленты в будущем, хорошая масштабируемость (добавить клиентов или устройств записи). Минус: достаточно громоздкая конструкция, которая заточена под сетевое резервирование на ленты. Придется потратить какое-то количество времени на "разобраться/поэкспериментировать/потренироваться"
2. Дешево и сердито. Rsync, локально. Тут несколько вариантов:
а) одна большая свалка с инкрементальными копиями (если не удалять файлы в "каталоге-получателе"). От тупого удаления файла спасает. Есть минус - отсутсвует версионность инкрементов (т.е. если пользователь открыл файл, внутри него исправил цифры и сохранил, то мы в архиве получим точно такой же файл и откопать старые цифры уже нельзя).
б) свалка не одна, а несколько. Место будет жрать пропрорциональко количесву необходимых версий инкрементов. Придется корябать скрипты самому на основе тех, что уже валяются в сети. Хотя вариант не шибко сложный.
Со снапшотами хорошо дружит только NetApp со своим WAFL, но это уже совсем другая песня.
Bacula не пройдет. Многие юзера работают со своих ноутов, и ловить их, чтобы поставить клиент - дело довольно сложное. Или я что-то путаю?Версионность нужна. Так что пока остановлюсь на версии с много свалок и скриптами.
>Bacula не пройдет. Многие юзера работают со своих ноутов, и ловить их,
>чтобы поставить клиент - дело довольно сложное. Или я что-то путаю?Бэкапить хранилище, а не отдельных клиентов.
rdiff-backup ?
Может быть rsnapshot сгодится? Я использую примерно для таких же целей - защита от "Оёёй! Вот тут мегаважный файлик случайно (а бывало, что и специально) потёрли! Как бы вернуть?" :-) В целом доволен. Правда, объёмы данных у меня почти на порядок меньше (ок. 100G).
А у него есть какие-нибудь требования к среде обитания? Гугл на эту тему помалкивает...
>А у него есть какие-нибудь требования к среде обитания? Гугл на эту
>тему помалкивает...Собственно, на сайте этой проги можно посмотреть: http://www.rsnapshot.org/
У меня она обитает на сервере, сделанном из самого обычного компа с двумя дисками SATA 250G. На первом система FreeBSD с Самбой и файлы пользователей, а второй полностью отдан под хранение резервных копий, которые делает rsnapshot. Одновременно держу 6 "часовых" копий, 7 "дневных" и 4 "недельных". При этом, что приятно, на втором диске занято места лишь на 10% больше, чем на первом.
>[оверквотинг удален]
>>тему помалкивает...
>
>Собственно, на сайте этой проги можно посмотреть: http://www.rsnapshot.org/
>
>У меня она обитает на сервере, сделанном из самого обычного компа с
>двумя дисками SATA 250G. На первом система FreeBSD с Самбой и
>файлы пользователей, а второй полностью отдан под хранение резервных копий, которые
>делает rsnapshot. Одновременно держу 6 "часовых" копий, 7 "дневных" и 4
>"недельных". При этом, что приятно, на втором диске занято места лишь
>на 10% больше, чем на первом.Немного запутался в хавту и манах. 6 "часовых" копий - это 24/6, т.е. копии раз в 4 часа, или 6 копий, сделанных с промежутком раз в час?
>Немного запутался в хавту и манах. 6 "часовых" копий - это 24/6,
>т.е. копии раз в 4 часа, или 6 копий, сделанных с
>промежутком раз в час?Нет, немного не так. Процесс управляется кроном. В /etc/crontab у меня прописано вот что:
10 6,9,12,15,18,21 * * * root rsnapshot hourly
20 22 * * * root rsnapshot daily
40 22 * * 7 root rsnapshot weeklyА в конфиге:
interval hourly 6
interval daily 7
interval weekly 4Часовые копии делаются в 6:10, 9:10, 12:10, 15:10, 18:10 и 21:10. Вполне возможны и другие часы с минутами и количество копий на свой вкус. Сервер обслуживает контору, которая по ночам не работает, поэтому и резервные копии по ночам делать смысла нет, а с 6 до 21 часа делаются каждые три часа. Вечерком подбивается дневная копия (очень быстро из соответствующей часовой), а в конце недели - точно так же недельная (из дневной).
>[оверквотинг удален]
>interval daily 7
>interval weekly 4
>
>Часовые копии делаются в 6:10, 9:10, 12:10, 15:10, 18:10 и 21:10. Вполне
>возможны и другие часы с минутами и количество копий на свой
>вкус. Сервер обслуживает контору, которая по ночам не работает, поэтому и
>резервные копии по ночам делать смысла нет, а с 6 до
>21 часа делаются каждые три часа. Вечерком подбивается дневная копия (очень
>быстро из соответствующей часовой), а в конце недели - точно так
>же недельная (из дневной).Спасибо за помощь! Завел, пока что в тестовом режиме. Если все пройдет гладко при таком объеме данных - перенесу на постоянку.
>А у него есть какие-нибудь требования к среде обитания? Гугл на эту
>тему помалкивает...Судя по описанию с сайта
rsnapshot is written entirely in Perl. It should work on any reasonably modern UNIX compatible OS, including: Debian GNU/Linux, Red Hat Linux, Fedora Linux, SuSE Linux, Gentoo Linux, Slackware Linux, FreeBSD, OpenBSD, NetBSD, Solaris, Mac OS X, and even IRIX.
никаких проблем не должно быть ибо perl ;)
Не забудь поделиться впечатлением, интересно. У самого объемы бекапа достигают 500-600 Гб.
Решено. Rsnapshot.