Рубрика «резервирование данных»

Да, я тоже бываю дебилом. Но такого я от себя не ожидал. Вроде бы «не первый год замужем». Вроде бы читал кучу умных статей об отказоустойчивости, избыточности и т.п., что-то разумное когда-то написал даже сам тут. Свыше 10 лет являюсь CEO хостинг-провайдера работающего под брэндом ua-hosting.company и предоставляющего услуги хостинга и аренды серверов в Нидерландах, США, а буквально неделю назад и в Великобритании (не спрашивайте, почему название ua, ответ можете найти в нашей автобиографической статье), предоставляем клиентам решения различной степени сложности, иногда такой, что даже сами затрудняемся разобраться в том, что сотворили.

Но блин… Сегодня я превзошёл сам себя. Мы сами себе полностью снесли сайт и биллинг, со всеми транзакциями, данными клиентов об услугах и прочим и в этом виноват был я, я сам сказал «удаляй». Некоторые из Вас уже заметили это. Это случилось сегодня, в пятницу в 11:20 по восточному североамериканскому времени (EST). Причём наш сайт и биллинг размещены были не на одном сервере, и даже не в облаке, мы ушли из облака дата-центра 2 месяца назад в пользу нашего собственного решения. Всё это размещалось на отказоустойчивом гео-кластере из двух виртуальных серверов — нашего нового продукта, VPS (KVM) c выделенными накопителями, НЕЗАВИСИМЫХ VPS, которые располагались на двух континентах — в Европе и в США. Один в Амстердаме, а другой в Манассасе, под Вашингтоном, тем, что D.C. В двух надёжнейших дата-центрах. Контент на которых постоянно и в реальном времени дублировался, а отказоустойчивость основана на обычном кластере DNS, запросы могли приходить на любой из серверов, любой выполнял роль MASTER, и в случае недоступности брал на себя задачи второго.

Я думал, что это может убить только метеорит, ну или ещё что-то подобное глобальное, что может вывести из строя два дата-центра одновременно. Но всё оказалось проще.Читать полностью »

Данная статья предназначена конечно не для админов, а скорее для веб-разработчиков, у которых на сервере неспешно наполняется БД небольшого объема. И вроде бы данные туда так и поступают — неспешно и небольшие, и ничто не предвещает беды, но все равно как-то не по себе. А вдруг завтра случится микроколлапс внутри данного конкретного сервера или данной конкретной хостинг-компании. И везде мерещатся злые хакеры и боты.

В общем, чтобы спать спокойно, нужно обеспечить периодическое сохранение содержимого БД вне рабочего сервера на случай, если по каким-то причинам доступ к содержимому сервера будет утерян. Для тех, кто (как и я) не дорос еще до репликаций БД на отдельных серверах, мой ответ — отправляйте дампы по почте.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js