Последнее время ознаменовалось падением сразу нескольких хостеров, некоторые из которых были достаточно крупные. Некоторых моих заказчиков коснулись эти проблемы, так что я знаю о ситуации не понаслышке. Наблюдая за развитием ситуации на публичных площадках не удержался и сделал скриншоты наиболее эпичных высказываний пострадавших.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Я немного с юмором прокомментирую высказывания некоторых людей, хотя прекрасно понимаю, что пострадавшим совсем не до смеха. И тем не менее, пусть эта статья будет лишним напоминанием о том, что нужно делать бэкапы, причем не просто делать, а:
- Размещать их на внешнем сервере.
- Проверять их создание.
- Разворачивать их и убеждаться, что они рабочие.
Начнем с известного публичного сервиса. Как оказалось, он тоже не делает бэкапов. Удивительно, но факт.
Тут целая инфраструктура развернута была. Наверняка весь офис на ней работал. Тут и телефония, и crm и сайты. Бэкапов почему-то не было. Интересно, почему?
Клиентов в данной ситуации понять можно. Я бы тоже офигел от того, что кто-то не делает бэкапы в 21-м веке.
Это классика жанра. Бэкапы делаем, проверяем и кладем у того же хостера. Часто слышу такие предложения у заказчиков - давайте возьмем еще один сервер тут для бэкапов. А что, удобно все в одном месте держать. Проще оплачивать, документами обмениваться.
Еще одна стандартная ситуация. Бэкапы были настроены, но в какой-то момент они перестали создаваться. Для этого надо настраивать мониторинг бэкапов.
Это пример простой неудачи в квадрате. В декабре умирает на несколько дней ihor, человек переезжает на Мастерхост, а он умирает в начале марта. Не повезло, и добавить нечего.
Человеку повезло. Всего-то двухлетней давности архив. Интересно, насколько он актуален и можно ли считать, что архива нет в таком случае?
Хостер всего лишь прилег на 3 дня, а вы сразу в панику впадаете. Надо понять и простить.
Еще один хранитель бэкапов у того же хостера, где данные. Он надеется, что хостер сейчас как-кто в ручном режиме отдаст ему бэкапы, когда у хостера просто отжали серваки, заблокировав доступ в ЦОД.
Человек делится личным опытом, который безценен. Хранить бэкапы на том же диске могут не только пользователи, но и хостеры! Не стоит надеяться на их бэкапы. Делайте всегда свои.
3 дня ждут! Интересно, сколько еще готовы ждать? Я обычно переезжаю, если простой 6 и более часов. Если хостер такое допускает, то лучше с ним прекратить сотрудничество. Чем раньше начнешь переезд, тем быстрее все восстановишь. В описываемых мной случаях хостеры прилегли на несколько дней. А мастерхост уже 5 дней лежит. ihor хоть через 3 поднялся почти полностью.
Это просто пару примеров того, что может ответить тех. поддержка. Она у любого хостера ни за что не отвечает и вы спокойно в один прекрасный день можете услышать, что извините, но ваших данных больше нет.
Подать в суд, конечно, можно. Но какой смысл? Суд файлы все равно не вернет, а судебные издержки даже в виде потерянного времени будут выше, чем компенсация.
Доведенный до отчаяния пользователь хостинга Мастерхост после трех дней ожидания готов на неожиданные поступки. Человек решил применить ведические практики для торжества справедливости.
На этом моя подборка заканчивается. Надеюсь, было хоть немного интересно. Изначально, хотел поместить этот материал в раздел юмор, но посчитал все же, что не совсем уместно. Я лишь хотел лишний раз напомнить, как оно может сложиться.
Куча людей не понимают, что хостер и ваш сервер могут просто в один прекрасный момент исчезнуть вместе с вашими данными, магазинами, бизнесами и т.д. Нужно быть всегда готовым к этому, делать бэкапы и проверять их. Не надо экономить на тех. поддержке. Наймите кого-нибудь хотя бы удаленно на частичную занятость, если сами не умеете, делать ваши бэкапы, разворачивать их и присылать вам еженедельный отчет о проделанной работе.
В завершении пару моих материалов на тему бэкапов:
Это простые и надежные решения, позволяющие в сыром виде копировать ваши данные и в случае проблем очень быстро их разворачивать.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Rclone стоит внимания, успешно сливаю с помощью него данные в гугл диск
Да, хороший софт. Я с его помощью кладу бэкапы в s3 хранилища.
Это про "9,5 правил ведения безопасного бизнеса в России" на Хабре.
Не очень понятен настрой статьи. Смысл смысл - ок, посыл эмоциональный.. ну такое себе.
https://serveradmin.ru/bekap-sayta-wordpress-na-yandeks-disk/ - Данный метод, как выход из ситуации с айхорами и мастерхостами выглядит не очень ценным и как-то понижает граду сатиры. Причина - яндекс меняет условия использования своего сервиса по своему усмотрению и без предупреждений. Тем более это касается бесплатного доступа, который не предназначен для бизнес-решений.
Ссылки: https://habr.com/ru/post/489492/
https://www.ispsystem.ru/news/yandex-drive
https://yandex.ru/blog/apidisk/problemy-pri-otpravke-faylov-po-webdav
https://qna.habr.com/q/677787
.....
Не сообщал ли о проблемах мониторинг бэкапов и как там регулярная проверка их разворачиваемости?
Я же не говорю, что яндекс.диск достаточное решение. Это просто вариант очень дешевого хранилища. Я его использую как одно из хранилищ для холодных данных. Если что-то более надежное и гибкое надо - s3. Но по факту там тоже всякие проблемы бывают и мониторить сложнее. Надежнее всего - rsync. С ним у меня отказов и проблем никогда не было. Сырые данные очень легко проверить на актуальность.