Некомпетентность техподдержки masterhost

Кстати насчёт бекапов.

Я тут на днях написал им письмо:

А вот ответ

Может быть я неправильно задал им вопрос, что его не так поняли ?

Или .m нравятся такие переписки ?

Или они специально тянут время ?

>>"Поймите, те бэкапы обычно лежат на том же сервере, что и сами впс"

афигеть. а смысл ? дохнет винт - дохнет и площадка и бэкап Одновременно.

ту ТС: ...совершенно бесплатный совет для денежных проектов - если проблема не решена в течение суток - меняете днс у регистратора и перезжаете на более правильный вдс и манибэк. этой самый менее угарный вариант. вы же у себя копию держите своего добра?

для примера на том же лаеертече дохлый винт меняют в течение 4-6 часов ( за сентябрь десяток тикетов с реагированием не более 6 чсов было)

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

не тот ли это хостер, который кому недавно то выставил 7 килобаксов за "ддос" за выходные?

Cмысл, как обяснил m., тут в том, что если клиент что-то сам серьезное напортачит со своим VPS,

то сможет быстро вернуться к работоспособному VPS из бекапа Virtuozzo.

В моем случае полетел сам VPS и резервная копия бекапа Virtuozzo, потому что они действительно

были на одном сервере, при этом, согласно договору, с m. взятки гладки и он может

забить на восстановление данных, попрусту сказав, что данные утеряны.

Спасибо за поддержку, каждый из нас может оказаться в такой ситуации, а знание приходит

с опытом. Что касается бекапа по rsync, то тут планировалось по cron-у раз в неделю целиком копировать весь VPS и ежедневно копировать дампы баз данных MySQL и текстовых баз, которые достаточно часто меняются. Только реализовать в жизнь такой автобекап мы не успели (VPS-у этому не более 2х месяцев), VPS накрылся ранее.

Если что-то не получается у m., как показывает практика, клинта начинают дезинформровать

и кормить обещаниями, лучше бы уж честно говорили все как есть.

Спасибо за совет. Дело тут в том, что различные MySQL базы данных, базы по выплатам партнерам

находстя в единственном экземпларе на стороне .m, т.к. мы не успели снять бекап VPS для себя.

Скрипты все, естественно, у нас остались от сайтов.

DNS мы позавчера сменили, чтобы выводилась страничка с текстом об аварии для сайтов, упавших на VPS и чтобы сайты участников, которые размещали js-коды нашей партнерки не тормозили в связи с недоступностью VPS.

по поводу этого не в курсе, поясните о чем именно речь?

Буду благодарен всем, кто подскажет в личку схемы автобекапа "больших" серверов и порекомендует надежные и стабильные (можно не распространенные) компании,

предлагающие услуги выделенных серверов.

Парадоксально, но элементарный бэкап ощутимо меньше нагружает систему ;) Rsync хорош только в том случае, когда надо экономить трафик и есть очень много свободных системных ресурсов.

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

остается вероятность, что из-за стихийных бедствий (пожара в ДЦ, проблем с электорпитанием ДЦ) данные как на самом сервере, так и на бекапном сервере утеряются.

могу без лички, может кто-то поправит,

в рельности делаеют некоторые (миниум 10 человек с форума таких знаю) поступают так:

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

на одной машине и мастер и слейвмускулевые , бэкапы базы осуществляются с слейва ( ибо --opt блокорует таблицы),

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

быстрее я еще ничего не встречал.

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

у меня складывается следующая схема работы и автобекапа для сохранения

данных на достаточно большом выделенном сервере:

1) ставить RAID1 (можно программный) и два винчестера для зеркалирования информации - это спасет в случае если на одном винте данные попортились - будут браться данные с другого винчестера и сайты на сервере будут продолжать функционировать (а сломавшийся винт заменяется оперативно);

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

3) раз в неделю по rsync копировать на удаленный (второй сервер) копию всего сервера целиком,

и раз в сутки с ее же помощью копировать на удаленный сервер копии текстовых и MySQL баз данных.

Только так вижу надежность от утери данных, есть замечания?

RAID не спасает от порчи данных. Он способен примерно в 50% вылета диска не потерять все данные. В некоторых случаях рэйд может стать виновником порчи данных :) Фактически основная задача рэйда, это повысить отказоустойчивость системы, скажем повысить сетевой аптайм. Для нормальных целей лучше два отдельные диска.

Чем проще система, тем она надёжнее ;) Тот же rsync, это не для бэкапов, так как при порче оригинала, автоматом портится и копия... Если нужна надёжность, то надо попросту дублировать количество независимых хранилищ.

По сути рэйд для повышения отказостойкости (можно и отказатся для типичных проектов), первый вынесенный из впс/сервера бэкап на том же датацентре и вынос за пределами датацентра на случай форс мажор.

Подходить надо гибко, по этому бесмысленно тупое ежедневное резервирование целиком акаунта, впс или сервера, это пустая трата ресурсов. Типично меняется только определённые каталоги и база данных. Бэкапа в объёме до 1 - 2 ГБ должно хватать почти всем. Вот именно по этому лучше, когда бэкапом заботится/заказывает сам хозяйн.....

тут все зависит от реализации rsynс, разумеется, действовать так примитивно как вы написали

мы и не собирались, имелась в виду примерно следующая схема:

1) сначала делаем архив на первом серваке нужных нам папок с уникальной датой например 07.zip, а затем переносим это дело по rsync на второ сервер в папку /backup

2) а спервого числа rsync будет затирать старые копии новыми на сервере 2, т.к. команда синхронизирует файлы.

3) если что-то поломается на первом серваке по wget берем прямо нужный архив, распаковываем его на сервере 1

Читайте внимательнее что я писал выше - там указано, что копия резервная будет делаться

раз в неделю для всего сервера целиком. конечно, на копию всего сервера тратяться приличные ресурсы, поэтому данная копия будет делаться ночью с 2 до 7 часов.

Вариант который предлагаете вы не вполне годится для "горячего" разворачивания сервера

на другом хостинге, т.к. придется сперва настроит саму операционку, а уж затем и

копировать те "нужные" папочки с файлами данных.

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

только нужные папки содержимое которых меняется регулярно.

Вы не разверьнёте оперативно на другом железе свой бэкап, даже копию впс не развернёте, если ноды не ваши. Поверьте, я быстрей настрою систему, и залью данные, чем Вы распакуете свой бэкап.... Я же не зря намекаю на то, что гениально только то, что элементарно ;)

На сим откланяюсь, так как убеждать не вижу смысла.