Где хранить бэкапы - выбираем лучшее.

Все равно есть время (период) максимальной и минимальной нагрузки.

С точки зрения концепции выглядит не совсем правильно, какой мне смысл делать синк по крону (раз ето крон, ето значит раз в X времени), если у меня проходит процедура бекапа и только после нее надо 1 раз отлить это все на отдельный сервер, разницы между например rsync или ftp или scp в данном случае не вижу, так как первый "отлив" идет на локальный сервер... то есть 100Mb/s...... Тут разовая точечная задача я бы так сказал, по этому как тут применять задачи крона - не знаю, по моему не уместно. Но в целом где-то так и выглядит, создал бекап, подготовил на бекап сервере папочку с датой, слил туда.... Кажется все и так довольно просто :)

Romka_Kharkov добавил 31.03.2011 в 20:23

Дадада +1 однозначно, но !!!! в случае работы с бекапами и данными вы рано или поздно приходите к тому, что начинаете понимать сколько каждый из ваших клиентов потребляет и начинаются поиски оптимизации данного процесса, в моем случае я делю клиентов на группы в процессе построения бекапов , сперва бекап делается для тех у кого < 2 GB информации, с точки зрения нагрузки на сервере tar не дает никакой мега ядерной нагрузки... .пока пакует до 2 GB информации.... а вот те кто > 2 GB собираются потом, с интервалом в 10-15 минут, что бы мнимый load average мог успеть рассосаться и не писали ночные клиенты...... А если запустить тупо всех под ряд... да, можно среди ночи наступить на мину :))))

Дык наступали и не раз а то б не покупали лицензии R1Soft :) У R1soft есть свои тараканы - как у любого решения но, в чем точно ему отказать нельзя - при нормальной работе систем нагрузки на пациента - НЕТ. Если придет злобный хакер и сделает rm -rf / - не вопрос - восстанавливаете образ диска полностью (один в один) и живете дальше. Ну какой файловый бекап такое может сделать ? А в том что бекап дело нужное можно убедиться тут же не отходя от кассы: даже здесь, только на серче, сколько случаев было полной или частичной потери данных на дисках у хостеров ? много.

PS. И между прочим статистика одинаковая - что хостеры с рейдом, что хостеры без рейда.

Да ну ладно, это по теории вероятности не возможно :)))) Как могут быть разные проценты у тех кто защищен доп. винтом и у тех кто не.... Но образ, это штука тоже не простая.... файловый бекап скажем так дает несколько иные возможности, он так же легко и быстро восстанавливается, например та же cPanel. Если у меня умерло все... типа новый сервер нулевый + есть бекапы:

Накатывается ось: минут 10-15

Накатывается cPanel: до 30 минут.

Распаковываем все архивы: (В зависимости от объема)

Все продолжает работать.

Я конечно не буду спорить, что блочная запись будет быстрее, но стоит ли платить за это?

Давайте может попробуем сверить производительность схем?

Сколько у вас по времени занимает скажем создание образа при (допустим) 100 GB данных у клиентов? Свой путь восстановления я описал, как выглядит ваш? коммерческий....

Схема работы такая (порты подключения у серверов - 100 Мбит, сервер в одном ДЦ (США), хранилище в другом ДЦ (Германия):

1) Создается первый образ - занимает в завимости от объема данных от часа до даже дня (если диск сервера это сата диск на котором шарятся пару тысяч доменов/сайтов).

2) Настраивается регулярный бекап с периодичностью от нескольких минут (да, такое тоже возможно теоретически но, техническая возможность зависит от скорости передачи данных и чтения/записи на диски) до ежедневного или почасового.

3) Настраивается количество хранимых "слепков" (скажем хранить почасовые слепки в течение 3 дней - это 72 слепка.

Пояснение - первый бекап и "слепки" к нему - это по сути инкрементальный бекап только реализованный на ином способое доступа к данным. Поэтому объем передаваемых данных сильно уменьшается. Скажем на 100 Гб полных данных этот объем может составлять 0.5 - 1 гиг.

Если нужно выдернуть часть данных которые клиент про*ал по каким то причинам, клиент может сходить в юзерскую панель хранилища (если речь идет о спанели, директадмине, плеске), просмотреть свои файлы за нужный период времени, отметить их для восстановления и восстановить.

Если это владелец сервера которому сделали rm -rf / - не беда. Сервер форматируется, устанавливается агент, агент запускается в режиме BMR (Bare Metal Restore) и после восстановления агент перезапускает сервер и сервер загружается ровно в том виде в котором был до rm -rf / В каком точно виде - зависит от того как часто делали бекапы.

Времени это в нашей схеме занимает прилично - нужно ведь передать 100 гигов по сети из одного дц в другой. Но примерно столько же времени займет и перекачка обычных архивов с удаленного фтп или рсинк сервера. Только к этому еще добавится время разворачивания бекапов и дальнейшей подчистки настроек сервера напильником (перекомпиляция апача + пхп и т.п. и т.д.) .

Время восстановления в версии CDP 2.0 это наиболее было узкое место. В версии 3.0 данные хранимые в хранилище можно тупо копирнуть на второй диск, воткнуть его в сервер подлежащий восстановлению и с этого диска и восстановить сервер (сама схема восстановления ничем не отличается просто убираем перекачку по сети что и составляет большую часть времени).

Кто-нибудь пользовался http://setvps.ru/index.php?page=backup под бекапы? Цены очень заманчивые :)

школохост? я бы не рискнул, бэкапы это святое)

Дорого. у fornex.com 50 Гб за 140 рублей :)

Если не школохост, то у ihc.ru за эти деньги можно получить уже 75 Гб ;)

у fornex саппорт тугой, ночью задал вопрос в обратную связь, до сих пор ответа нету...

setvps.ru хоть ответили быстро...

у меня быстро отвечают, в течение 30 минут. Но мне он не нужен, мне главное объем дискового пространства и хорошие каналы. :)

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