Беда. Хостер снес 10000 постов с форума.

Выделение места под резервные копии и отвечать за резервное копирование это немного разные вещи. Хостер как раз предоставляет только место под бекапы, а клиент сам за них отвечает

XLhost.Ru, если клиент оплатил хостеру настройку резервного копирования то оно должно работать, а не делать вид что работает

и не нужно рассказывать что все может сбоить и ломаться

AndyM, Что то я не нашел сообщения от ТС, где он сообщил, что оплатил настройку резервного копирования. Он платил за 10 гб на удаленном сервере, а не за проверку работоспособности его бекапов, тем более ТС сам написал, что место на FTP закончилось, поэтому бекапы и не делались, за это отвечает уже сам клиент, а не хостер. А если клиент не хочет самостоятельно это контролировать, то нанимает администратора.

---------- Добавлено в 15:07 ---------- Предыдущее сообщение было в 14:59 ----------

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

Разовая настройка и постоянное администрирование тоже разные вещи и стоят разных денег.

Вина хостера ровно в одном - невнимательности саппорта

magellan1 очень жаль что у Вас все так сложилось. Судя по всему, проект крупный и нужно было самостоятельно страховаться от подобных ситуаций. Действительно, многие хостеры заявляют о том что делают ежедневный бекап, но по факту все это обходится одной или двумя разами в неделю.

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

P.S - своим клиентам на хостинге честно говорим, бекап делается минимум 1 раз в два дня. Раз в неделю все бекапы сливаются на отдельный резервный сервер. Всегда всех предупреждаем и просим страховаться, путем сохранения бекапов из панели на свой жесткий диск. Как говорится доверяй, но проверяй.

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

Нет, почему-же, просто интересно, сколько хостер берет за услуги и на каких условиях

Сожалею, сам попадал в подобную ситуация с хостингом РБК (2 недели), поэтому полностью на стороне клиента. Совет тут реально один - на будущее самостоятельно делать бэкапы важных сатйов по мере возможности.

Плати, не плати, а клиент всегда виноват.

На будущее предлагаю не платить за резервное копирование и самостоятельно складывать копии к себе.

Добрый вечер!

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

По поводу того, что было с файлами изначально - мы подозреваем удаление определенных файлов СУБД либо явный DROP таблиц, так как сообщений о повреждении таблиц в логах не было, поэтому и был предложен вариант починки не СУБД, а непосредственно восстановление данных, что мы и выполнили.

По поводу нашей отвественности за работу системы резервирования в ISPManager - если кратко, то мы не можем отвечать за работу совершенно сторонней нам системы. Мы предоставили платно Вам доступ на FTP для резервирования, помогли единожды настроить бэкап средствами панели, проверили его работу, когда это выполнялось - он работал. Почему он перестал работать потом - я Вам сказать не могу, какой-то сбой панели, за который, опять же, мы не несем никакой отвественности по той причине, что мы не обеспечиваем и не заявляли постоянное администрирование сервера, мы выполнили лишь отдельную операцию. Если бы Вы попросили нас через неделю проверить как работает бэкап и разобраться, что с ним - мы бы безусловно помогли (впрочем, мы поможем и сейчас, лишь попросите), но самостоятльно обнаружить отказ системы резервирования на машине, к которой у нас в принципе нет доступа - невозможно, сожалею.

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

---------- Добавлено в 19:40 ---------- Предыдущее сообщение было в 19:38 ----------

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

---------- Добавлено в 19:44 ---------- Предыдущее сообщение было в 19:40 ----------

Благодарю за поддержку в техническом контексте! Именно так, в среднем на ноде 10-15 миллионов файлов и сотни ГБ мелких данных, мы раньше пытались их резервировать, но полный бэкап, во-первых, выполняется около 3х суток, а, во-вторых, почти полностью перегружает дисковую систему, сводя качество услуги на нет, поэтому комплекс мер по защите данных клиентов сводится к использованию RAID массивов, обеспечивающих целостность данных при физическом отказе дискаов, а также мониторингу состояния файловой системы на серверах.

Данный бэкап был не наш, с уровня ноды, а из панели ISPManager.

---------- Добавлено в 19:46 ---------- Предыдущее сообщение было в 19:44 ----------

Таблицы не были повреждены, СУБД работала без сбоев, просто данных в таблице не было и все. Впрочем, вины Григория я не отрицаю, она есть.

Ну вот и разобрались. Я думал услуга бекапа была но не работала, а оказалось что это всего лишь место для него на выделенном фтп