Вопрос в следующем:
- TimeBackUP не может работать с включенным кэш, или это баг, потому как установленный по умолчанию пакет "Резервирование и репликация" с активированным кэш работает прекрасно?
- В чем принципиальная разница пакетов TimeBackUP и "Резервирование и репликация" ?
- Так ли необходим кэш на чтение-запись, влияет ли наличие кэш из SSD на сохранность данных?
- Хотелось бы услышать общие рекомендации по используемому Рэйд 10 (Рэйд 5 и 6 не рассматриваю) , потому как планируется перенести все шары со всех серверов предприятия на данный раздел, интересует надежность и сохранность данных, как говорится рейд рейдом а BackUP никто не отменял, какой пакет из существующих посоветуете чтоб архивировал по расписанию и была возможность хранить несколько копий данных
Я немного поэкспериментировал с ТаймБэкапом (смотри где-то тут: http://www.synology.forum/index.php?s=&...st&p=56131)
И в результате совсем от него отказался, какой-то он мне глючный и недоделанный показался... Основная моя к нему претензия - иногда он пропускал целые папки (недобэкапливал :-) ), подозреваю потому что с файлами там кто-то как раз в это время работал и возникала sharing violation. Бекапы сино-пакетов тоже не делает. Ну и все таки наверное его основное применение - это бекап небольших объемов но часто изменяемых данных.
Сейчас пользуюсь для бэкапа родным Сино-бэкапом из "Резервирования и Репликации", бекаплю на другой Сино-сервер, причем там есть два варианта, не помню точно как они называются, один - это бэкап в shared folder, другой - бекап в volume (синологи еще его называют кажется archiving backup).
Первый из этих вариантов (в shared folder) не позволяет иметь копии файлов, только одна версия, но в принципе можно иметь два (или больше) бекапа в разные сетевые папки и бекапить в них по расписанию например по четным запускается один бекап, по нечетным другой, но это конечно геморройно. Этот вид бекапа удебен тем, что в папке бекапа лежат обычные файлы, их можно увидеть как с любого другого компа в сети (при наличии доступа, естественно), так и напрямую из ФайлСтанции сино-сервера куда делается бэкап.
Второй бекап, archiving, в volume, бекапит куда-то там в специальное хранилище, невидимое другими штатными средствами ни как шара, ни из ФайлСтейшн на целевом сино-сервере, только (?) только из родной же утилиты восстановления данных. Позволяет селективное восстановление и умеет делать версии бекапов и их ротацию.
Оба этих варианта бекапов делают бекапы сино-пакетов (некоторых), умеют делать бекапы конфигурации исходного сино-сервера и умеют запускаться по расписанию.
Я использую их оба, первый (который в shared folder, без версий) запускается каждый день, это оперативный бекап, на случай к примеру неисправности или рассыпания тома на основном сервере.
Второй, который archiving, с версиями, - запускается, насколько помню, раз в месяц, количество версий ограниченно свободным местом, я поставил пока 4, но если останется место или расширюсь - буду увеличивать пропорционально...
В плане еще попробовать перенести второй нас (который принимает бэкапы) в другую IP-сетку, на отдельном сетевом гнезде основного наса, разнеся трафики бекапов и основной сетки, разгрузив бекбон основной сети от бэкапов, хотя и так не сильно мешает.
Это моя конфигурация, основанна исключительно на моем личном опыте и я не претендую на исключительную правильность и единственную верность данного подхода, с удовольствием выслушаю разумную критику, замечания, советы и предложения.
Насчет идеи перенести все шары предприятия на один сервер и один раздел... Я бы хорошо подумал бы, даже если у тебя, будет скажем так - идеальный, бекап. Ведь шары могут слетать не только потому что у тебя харды слетели, но и например потому что сервак сдох, что ты тогда будешь делать?