серверов от Acer
Вчерашний пожар — очередной повод вспомнить о бекапах. Вспомнить, настроить и проверить. Держите 7 простых правил для собственников и руководителей бизнеса, которые помогут стойко перенести подобные катаклизмы.
Если инфошум о замедлении Твиттера вчера не позволил вам увидеть важное, то сообщаю. Вчера, 10 марта, произошел пожар в дата-центре провайдера OVH в Страсбурге, который входит в топ-5 крупнейших провайдеров. Полностью уничтожен центр обмена данными SBG2 (выгорел полностью) и на 30% ЦОД SBG1 (выгорело несколько боксов). Остальные 2 здания, находившиеся рядом, залиты водой.
Восстановление затопленных ЦОДов займет не менее 2 недель. В дата-центре размещались крупные европейские компании, часть из них уже заявили, что данные потеряны безвозвратно.
Не устаю напоминать о необходимости регулярного создания бэкапов, а тут как раз подоспел очередной повод.
Я руковожу небольшим Digital-агентством, обслуживаем малый и средний бизнес, часто общаемся с начинающими предпринимателями. И постоянно сталкиваемся с анти-кейсами резервного копирования, возражениями вроде «дорого», «сложно», «позже настроим», «пока не надо» и «само рассосется».
Хочу развеять сомнения руководителей, показать, что все просто, дешево и само не рассосется. Поэтому сегодня дам простой план резервного копирования, в большинстве случаев даже программировать не придется. Инструкция подойдет небольшим и средним компаниям, не имеющим собственной IT-инфраструктуры. Итак, начнем.
1. Купите отдельные IP-адреса для боевых проектов
Если у вас облако, сервер или VPS, то один IP-адрес уже в комплекте. Если у вас виртуальный хостинг, то докупите к нему выделенный IP-адрес. В нештатных ситуациях это поможет быстро сменить хостинг или перенести проект на другой сервер. Обойдется примерно в 99 руб. в месяц.
2. Используйте NS-сервера регистратора домена
Хостинг провайдеры предлагают перенести обслуживание DNS на свой хостинг. Не соглашайтесь, оставьте домен на NS-серверах регистратора домена, а в А-записи домена пропишите IP-адрес хостинга. Так вы сможете быстрее сменить хостинг в случае аварии. При изменении А-записи обновления распространятся в течение 1 часа, и ваш проект через час уже будет доступен на новом хостинге. Но если же вы будете менять NS-сервера, то обновления могу занять до 72 часов. Обычно регистраторы предоставляют услугу бесплатно, но RU-center хочет денег.
3. Включите локальное резервное копирование на хостинге
На виртуальном хостинге чаще всего уже включено резервное копирование. На VPS, выделенном сервере или в облаке вам нужно докупить услугу бэкапов самостоятельно, стоит в среднем 300 руб. в месяц. Да, облака тоже надо бэкапить. Резервные копии, которые хранятся на том же хостинге — это очень плохая идея. Они не спасут при крупной аварии, но такие копии помогут вам в разы быстрее восстановить бэкап при небольших проблемах с проектом.
4. Храните 1-3 локальных бэкапа
Как правило, дисковое пространство на хостинге стоит не дешево, даже если вы покупаете отдельный диск для бэкапов. Поэтому нецелесообразно хранить там большие объёмы информации. Храните только самые последнии копии за предыдущие дни.
5. Настройте резервное копирование на отдельный сервер
Я рекомендую использовать облака как основное хранилище резервных копий, но вы можете использовать и простой сервер или дешевый хостинг от другого провайдера. Главное, чтобы сервера этого другого провайдера располагались не в том же дата-центре, что и основной сайт. Но облака гораздо дешевле, хранение одного террабайта там стоит обычно около 500 руб. в месяц. Можно использовать Google Cloud, AWS или Yandex Cloud — для них есть готовые инструменты резервного копирования, поэтому их легко настроить. Обычно рекомендуют хранить 7 копий за неделю, 4 копии за месяц, 12 копий за год — так и сделайте.
6. Поверяйте бэкапы раз в неделю
Минимум раз в неделю проверяйте факт создания бэкапов и их размер. Любой сбой может нарушить вашу схему резервного копирования: смена пароля, обновление ПО, переполнение диска, нехватка денег на счету. Потратьте всего 2-3 минуты в неделю — этого хватит, чтобы предотвратить неприятности.
7. Восстанавливайте бэкапы раз в месяц
Хотя бы изредка восстанавливайте свои резервные копии на тестовом сервере. Идеально делать это раз в месяц, минимум хотя бы раз в 3 месяца. Одно дело иметь резервные копии, и совсем другое — иметь реально работающие резервные копии. Вы должны быть уверены, что в нужный момент бэкапы вам реально помогут и у вас есть возможность их быстро развернуть. Удобно и дешево можно разворачивать облачные сервера на reg.ru или hetzner.cloud, потратите максимум 100-200 руб за раз. Процедура займет всего 1-2 часа, но убережет от проблем в будущем.
Вот и все, просто соблюдайте хотя бы эти простые правила.
Инструкция не претендует на оригинальность и вряд ли впечатлит профессионалов. Но она для них и не предназначена. Профессионалы могут просто проверить свои бэкапы в очередной раз. Инцидент в Страсбурге снова показал, что даже профессионалы не всегда делают бэкапы.
Если вы не уверены в своих резервных копиях, то наша команда готова провести бесплатный аудит вашей системы резервного копирования и дать соответствующие рекомендации.
Пишите в комментариях свои идеи как еще больше упростить схему, ускорить восстановление резервных копий и какие сервисы помогут сэкономить на бекапах.
У меня как раз данные расположены на OVH серверах. Мне повезло, сгорел не мой ЦОД. Так как у меня там развёрнуты экстремально мелкие проекты, то я использую простейшую схему бекапа. Раз в сутки скрипт копирует всё что нужно и сворачивает в архив. Тот в свою очередь загружает его через WebDAV на Яндекс.диск. Диск же синхронизирован с моим компьютером и физические копии находятся и в облаке и на диске. Параллельно скрипт шлет мне письмо на почту со статусом, прошло всё хорошо или нет. Для больших проектов не советую использовать данную схему. Тем более что существуют автоматизированные решения.
Яндекс вроде не так давно начал блокировать подключения по WebDAV, как раз из-за таких кейсов. Говорят, что сервис не для хранения резервных копий. У вас работает?
Я сейчас перепроверил. Всё работает. Я про это и не слышал даже. Сейчас погуглил, они отключили эту возможность в 2019 году, но весь 2020 у меня всё работало и до сих пор работает. Но я сейчас буду переделывать на другое хранилище. Спасибо за комментарий.
Опытный Влад
У вас работает?
В Nautilus удаётся смонтировать адрес davs://webdav.yandex.ru с паролем отсюда passport.yandex.ru/profile (ссылка "Пароли приложений").
В принципе не обязательно и webdav. Можно использовать их официальный консольный линукс клиент. Я подобным образом делал через крон-скрипт. по сути паковал в архив, запускал daemon диска копировал в папку, останавливал daemon yandex disk.
Нет просто bash скрипт. Расписание cron, отправка файлов curl, почтового сообщения тоже curl через smtps гугла. Ну и архив tar. Очень простой сценарий.
Круче чем AWS RDS Mutli AZ еще ничего не придумано. У Амазона в каждой локации есть изолированные дата центры, между которыми идет постоянная синхронизация. Если на один падает метеорит, то база автоматически переключается на второй без участия пользователя. То что многие не пользуются этим - трагедия.
Перебьют кабель между странами и адиос. Катастрофоустойчивость это не только несколько датацентров
Великолепный теркин30см
Ну если до такого дойдет, то что-то мне подсказывает, что бэкапы будут уже никому не нужны )
Ну СТО могут в жопу паяльник вставить и получить пароль к базе. Мы же не заставляем его ходить с анальной пробкой на кодовом замке (хотя у всех по-разному). Это я к тому что есть реальные риски которые можно оценить на основании истории провайдера, например, как часто выходили из строя одновременно две AZ. А есть фантастические, их брать в расчёт - сомнительная практика.
Вот как раз для защиты от "могут в жопу паяльник вставить и получить пароль к базе" пароль разделяют и делают многофакторную\многоуровневую аутентификацию
Не ну для обычной конторы понятно что два региона! достаточно. Хотя многим и такого не надо. ПРостой 1-2 дня спокойно переживут
Это да, но не пользуются по причине:
- непрозрачного ценообразования
- законодательства РФ
И все таки это выходит зачастую сильно дороже описанной схемы. Но удобно, да.
законодательства РФ
Ну мы же тут все глобальные интерпренеры, завоевываем мировые рынки.
непрозрачного ценообразования
А в чем непрозрачность?
И все таки это выходит зачастую сильно дороже описанной схемы.
Тут важно рассматривать глобальные затраты. Например, сколько времени разработчики тратят на автомасштабирование, резервные копии, отказоустойчивость. В любом случае именно программист, а не профессиональный SRE, имеет больший шанс ошибиться. Это тоже нужно учитывать при оценке стоимости облака.
А пользоваться подобным - тоже трагедия, ибо садишься на иглу жёсткого вендорлока. Убираешь один риск, получая десяток других
Всегда надо взвешивать риски и затраты. Использовать AWS оправдано для большинства компаний у которых администрирование инфраструктуры не их главный бизнес. Все-таки в таких конторах разработчики в первую очередь занимаются продуктом, а создание бэкапов и отказоустойчивость лучше доверить профессионалам. Здоровый скептицизм это всегда хорошо, но у AWS очень долгая история, на основании которой можно делать выводы. Microsoft тоже кажется хорошим вендором. Вот по поводу облачного бизнеса Google есть сомнения.
Ну мы же тут широко мыслим и строим наполеоновские планы по глобальной экспансии.
Странно, что не справилась система пожаротушения, её ведь именно для таких случаев должны были делать.
Странно, что не справилась система пожаротушения
Хорошая шутка.
Посмотрите в т.ч. и другие фото с пожара. OVH SGB2 — это промзона в захолустье, а в ней — "датацентр", построенный из *контейнеров*
— https://datarecoverymoscow.ru/images/misc/ovh-sgb2-datacenter-fire-burnt.jpg
— https://datarecoverymoscow.ru/images/misc/ovh-strasbourg-datacenter-fire-containers.jpg
— https://datarecoverymoscow.ru/images/misc/ovh-datacentre-fire-cloud.jpg
— https://datarecoverymoscow.ru/images/misc/ovh-cloud-sbg-fire.jpg
Что-то мне это напоминает... Ах да, ведь таким же образом сгорел Нотрдам де Пари
1. Очень спорно покупать себе отдельный IP, нет это полезно для того чтобы не залетать в какой-нибудь спам лист по IP из за соседа, но при пожаре никак не поможет.
2. Если у вас виртуальный хостинг, то вам придется переносить DNS на хостера, потому что хостер периодически меняет сервера и IP на ваши проекты меняются, если у вас DNS у регистратора, то при таких плановых работах сайты будут отваливаться. С другой стороны это древний миф, что DNS разносятся за 72 часа, на моей практике коренные DNS доменов с RU обновляются в течении часа/двух. Ну и DNS сервера это тоже сервера и у регистратора они или у хостера, они падают, по этому есть понятия primary DNS и secondary DNS
3. По сути бесполезное занятие эти ваши локальные бэкапы, заставьте разработчиков использовать git в конце концов.
4.А лучше 10 или 20, кто знает что может понадобится, чем больше тем лучше же =))
5. Вот это наверное самый ценный совет. Бэкапы должны быть как минимум за 200 км от вашего сервера, я храню в селектеле, там облачное хранилище выходит очень дешево.
6. Проверять бэкапы на то что делаются действительно стоит, только без фанатизма конечно же
7. Ну а тут да, я раз в месяц/два обновляю дев сервер как раз из бэкапа и проект актуализирую по данным и сразу работоспособность бэкапов проверяется
3. По сути бесполезное занятие эти ваши локальные бэкапы, заставьте разработчиков использовать git в конце концов.
Санитар! Тут парень базу в гите сохраняет!
Зачем вам локальная БД в бэкапе? Ну вот чисто интересно какой кейс использования её если в gzip 1Гб база будет весить пару мегабайт. Бэкап обычно нужен когда уже все, диски рассыпались, сервер сгорел (вместе с ДЦ) и так далее. В противном случае я не вижу смысла откатывать БД, для этого есть такие штуки как миграции и да они хранятся в гите.
Тут примитивная инструкция, для тех кто не в курсе про гит, кто обновляет движок на живую и не делает резервных копий перед релизом новых фич. Таких товарищей миллион, но их нет на хабре и виси, они не коментят посты. И с ними приходится работать.
Кейсы очевидные:
- сеошник обновил движок, все рухнуло
- контент-менеджер массово изменил свойства товаров - сломал базу
- из 1С выгрузили обновления прайсов - потерли структуру каталога
- установили непонятный модуль, он снес несколько таблиц в БД
И естественно нет никаких гитов и миграций БД, единственный вариант - откатить базу.
А как вы будете решать вопрос если в это время вам накидали уже 10-20 заказов, форм, лидов? Просто сотрете накатив бэкап? Может проще и дешевле не давать работать на живую? =))
Типичный заказ у нас - SEO-продвижение сайта, никаких доступов от сайта нет, разработкой у заказчика занимается какой-то свой подрядчик "на опыте". При этом у того "опытного" ни гита нет, ни бэкапов не настроено, как только что случается - он в кусты. Мы следующие, кому будет задан вопрос про восстановление сайта.
И вот только с этого момента заказчик начинает проникаться идее гита и бэкапов :) Тогда уже ценность и цена нашей работы возрастает в разы, настраиваем все как должно быть.
Так что вот про 20 лидов вообще не смешно, в среднем именно так и происходит раз в год с каким нибудь заказчиком. В этом случае делаем бекап того что осталось и откатываем сайт. И потом уже на тестовом сервере восстанавливаем сломанный сайт, достаем оттуда все что возможно и даем заказчику какой-то инструмент для просмотра этих данных. Если их можно смержить с продакшеном, то мержим.
Ну так и популяризируйте же эту методику, пишите правильные инструкции, а не выделенный IP и 4 локальных бэкапа, я как бы к этому и писал, просто сама суть бэкапов это не откатить что то, а восстановить в рабочее состояние. И создать бэкап перед началом работы, а потом его восстановить сильно затратнее, чем с гитом. Ну разве что не считая БД, но тут на живую просто ничего делать не стоит (ставить плагины, тестировать интеграции с 1С и так далее) и об этом не слова в статье.
Ну так и популяризируйте же эту методику
Это не среди заказчиков надо продвигать, а среди специалистов. Заказчик не поймет и вообще ничего не сделает.
выделенный IP
По всем вопросам вашу позицию понял и с ней согласен, но вот про IP никак не пойму. Чем вам IP так насолил? Очевидно же, что A-запись быстрее сменить, чем NS-сервера. Или вы этим никогда не занимались? В случае аварии недоступность сайта составит 30-60 минут, этого хватит, чтобы развернуть проект на другом сервере, и распространить обновление А-записи. Чтобы смена записи происходила быстрее нужно выставить TTL как можно ниже. При этом все остальные сервисы домена продолжат работать в штатном режиме. Если же NS-сервера менять при переезде на другой сервер, то распространение обновлений DNS займет в разы больше времени. И это зависит не от хостера, а от интернет-провайдеров по миру. На части провайдеров процесс займет больше суток, все это время сайт будет недоступен для пользователей.
Потому что я говорю про выделенный IP для виртуального хостинга, а вы говорите про "хостить DNS у регистратора доменных имен". Прочитайте свой же первый пункт внимательно. В A запись вам надо будет вписать другой IP в чем смысл выделенного тогда если вписать все равно нужно будет другой? Или всё еще не понимаете?
И заказчики все равно ничего не сделают, проблемы бэкапов это проблемы специалистов, а не заказчиков, я лично сразу говорю что надо, где надо и настраиваю, а они потом только оплачивают и всё, потому что для них, что сменить А запись в днс равноценна, как и завести проект в гит.
в чем смысл выделенного тогда если вписать все равно нужно будет другой?
В 10 раз повторю, что смысл в скорости обновления записей. NS-записи невозможно обновить у всех провайдеров за 5 минут, А-запись - возможно. Так понятно? Скорость переезда и восстановления возрастает в разы.
1. Ниже ответил. Время восстановления сильно снижается.
2. IP у хостера покупаются, они переедут вместе с хостингом. Обычно ничего не отваливается. Если падают NS, то доступность нарушается в любом случае. По итогу предложенный мной вариант несет меньше рисков.
3. Git не используется на большинстве небольших проектов. В реальности с этим сложно. Обычно проекты перманентно мигрируют между подрядчиками, кто-то настроит себе git, кто-то нет. Есть подрядчики, которые и слов таких не знают, и заказчик выбирает нередко таких из-за низкой ставки.
4. 20 дорого хранить и это не нужно. Локальный бэкап просто позволит быстрее восстановить данные, если не все сгорело. С того же AWS долго и дорого тянуть бэкап.
1. Каким образом? Вы можете IP перепривязать на другой сервер у другого хостера? Тогда уж проще поднять за 99р Load Balancer на базе Nginx и переключать там upstream
2. Вы мне кажется сами не понимаете что пишите. Вы советуете оставлять NS у регистратора, вписав туда A запись. А хостер хочет обслужить сервер (виртуальный хостинг, не VDS в облаке) и отключить его, он берет и перекидывает все на другой сервер с другим IP, если NS находятся у хостера, то он сам поменяет A запись в отличии от регистратора. Если вы боитесь что отвалятся DNS то тут поможет только secondary dns, так как у регистратора они тоже падают
3. Ну так я и говорю - заставить. Вписать в требования что хотим гит и все изменения фиксировать через него. Кто платит тот и заказывает музыку, разве нет? И заказчику плюс, ведь все разработчики используют гит (и не только разработчики), а если не используют значит их услугами лучше не пользоваться.
4. Проблему локальных бэкапов решает как раз таки git, любой файл можно откатить до любого состояние, посмотреть какие файлы испортили вирусы, что лишнего было загружено, кто внес изменения из за которых прод упал и все это просто и легко. Зачем вам 4 копии если гит может хранить изменения за всё время существование + система распределенная при наличии удаленного репа и в случае уничтожения у любого участника все равно останутся все версии. То есть гит покажет не просто изменения за 4 итерации назад, а вообще с момента инициализации
PS. Суть локального бэкапа как такова бесполезна, зачем вам локальный бэкап может пригодится особенно в 4 экземплярах? Ну чисто кейс какой-нибудь, просто интересно для чего хранить 4 версии локального бэкапа.
Вы можете IP перепривязать на другой сервер у другого хостера?
А чем проблема? Я никуда не перепривязываю IP, я выкидываю IP старого хостера и прописываю IP нового хостера. Всё.
Тогда уж проще поднять за 99р Load Balancer на базе Nginx и переключать там upstream
Мы сейчас точно говорим о непрофессионалах? :D
он берет и перекидывает все на другой сервер с другим IP
Вы же у него как раз для этого покупаете выделенный IP, этот IP привязывается к вашему проекту у хостера. Если ваш хостер делает так, как вы описали - меняйте хостера, он неадекватен.
Вписать в требования что хотим гит и все изменения фиксировать через него. Кто платит тот и заказывает музыку, разве нет?
Я так то не со стороны заказчика выступаю. Я как раз исполнитель, и где возможно, там мы конечно используем гит - это при разработке, на длительных проектах, на техподдержке. Другой вопрос, что если заказчик приходит с мелкой правкой, то гит накладно забесплатно разворачивать, кроме того у нас, например, есть проекты от которых в принципе нет доступов к серверу. Заставить заказчика использовать гит мы не можем.
Ну чисто кейс какой-нибудь, просто интересно для чего хранить 4 версии локального бэкапа.
Кейсы выше расписал.
И повторю, я за git, но в реальности 90% небольших проектов его не используют. Я тоже хочу жить в идеальном мире, но не всегда это получается.
Вы говорите купить отдельный IP, ну вот был у OVH отдельный и чем помог? Выделенный IP нужен не для скорости восстановления уж точно. Я еще понимаю если мы говорим за failover ip, но я боюсь что вы даже не знаете что это.
Вы странно как то повествуете, хотите жить в идеальном мире, но популяризируете какую то ересь, для проектов однодневок, которые сопровождают школьники на переменах. Вы либо трусы оденьте, либо крестик снимите =))
Для кейсов выше зачем вам 4 локальных бэкапа? Сеошник сломал сайт сегодня а узнали через месяц что ли?
Использование git это простота и он как минимум нужна исполнителю даже для мелкой правки, внедрить гит заказчику это считаем количество команд:
1. git init
2. git add .
3. git commit -a -m 'Я начал работать над проектом'
блин прям упаритесь, чтоб получить возможность откатить любые свои кривые изменения, лично мне кажется вы не работает с гитом, я не знаю не одного человека, кто бы сказал после использование гита повсеместно, что он кому то не нужен =))) И как же вы катаете без доступов на сервер и без гита заказчикам? По почте диски присылаете что ли с архивами изменений/патчами
PS. Хотя есть кейс, вас просят просто поставить в код яндекс метрику, тут наверное да, гит скорее всего будет лишним.
Уходите от хостера который меняет IP.
Например, за 10 лет ни на одном сайте в руценте не пришлось менять IP для моих клиентов. Хотя я бы его не рекомендовал, просто клиенты хотят домен с хостингом в одном месте.
Размещать DNS на хостинге тоже плохой тон. Даже если он же регистратор. Лучше всегда на независимой площадке.
Ну и боже упаси на хостинге хранить почту. Которая накроется вместе с сайтом, да и защита от спама всегда будет начального уровня.
beget меняет IP (бывает) и это один из немногих хостеров который предоставляет отличные услуги виртуального хостинга. Вы мне предлагаете уйти с великолепного по качеству услуг хостера, потому что у вас фобия оставлять DNS надежным компаниям? =) Да я им доверяю больше, чем DNS регистратора =)
Ну и использовать руцентр как хостера это вообще моветон =)
Чем почта на хостинге вас не устраивает? Вот у меня почта на хостинге работает без проблем, сбоев и всего прочего (сам настраивал), а мой знакомый за год мне звонит от 6 до 10 раз и сообщает о проблемах на яндекс коннекте =)
За все время работы в этой профессии, я понял что доверять нельзя никому, по этому надо уметь быстро (например плейбуки ансамбля) развернуть нужные сервисы (у меня упакованы в докере) где угодно и тогда где и что у тебя и у кого на самом деле вторично. А если я работаю на проекте, где простой невозможен, то там всегда настраивается избыточное резервирование, что даже если ДЦ сгорит то простоя не будет.
Советы слегка удивили.
1. Каким образом купленный выделенный IP поможет вам защититься, если его покупают там же где хостятся? Совсем никак.
2. Замена днс сейчас практических у всех происходит за 2-3 часа. 72 часа устаревшие данные. Редкие мамонты меняют за 72 часа.
Все остальные советы размыты и по сути должны были звучать так: Делайте бекапы и обязательно в другое место, не связанное с вашим хостингом.
IP позволит вам направить A-запись на хостинг, используя NS регистратора. В случае переезда вы просто меняете IP в А-записи. Иначе вам придется менять NS-сервера. Распространение обновленных NS происходит в разы дольше. Распространение обновленной А-записи займет 10-15 минут, максимум 1 час.
72 часа не миф, а стандарт. Понятно, что это предельный срок, обычно обновление происходит за 4-12 часов. Для коммерческого проекта 12 часов - очень неприятный срок, поэтому лучше выделенный IP - за час как раз можно развернуть проект и обновить А-запись. В общем, при аварии это сильно снизит время восстановления.
IP позволит вам направить A-запись на хостинг, используя NS регистратора. В случае переезда вы просто меняете IP в А-записи. Иначе вам придется менять NS-сервера. Распространение обновленных NS происходит в разы дольше.
Не очень понимаю что вы тут имеете в виду. Правлиьно я понимаю что есть хостинг без IP?
Я только сейчас понял почему человек со мной спорит выше, оказывается он просто не знает, как узнать IP адрес сервера не взяв выделенный в аренду. Ему нужен выделенный чтоб показали, что именно вписать в доменную зону.
Вы пишете неверно: IP адрес вне зависимости куплен ли выделенный либо шаред получен у хостера - прописывается одинаково по времени. И главное тут: IP адрес вы покупаете у хостера где на тот момент сайт размещён, никаким образом он защите от падений не поможет. И вообще нет разницы что вы прописываете IP адрес или просто новые ДНС сервера, все будет одинаково.
Вероятно вы спутали с подключением например ДНС сторонник, как Яндекс ДНС, где прописываются IP адреса, но тут никакой разницы нет по скорости восприятия новых ДНС. Без обид дружище, но надо еще подтянуть мат. часть.
Мойте руки перед едой, чаще подтирайте жопу.
И всё равно это не защитит вас от простоя для восстановления систем, разве что данные будут не все утеряны
постоянно сталкиваемся с анти-кейсами резервного копирования, возражениями вроде «дорого», «сложно», «позже настроим»
Хорошо, что вы пишете про бэкап онлайн-дел, но тогда бы стоило хотя бы упомянуть копирование локальной (офисной) информации.
Тех, кто ничего не бэкапит, ничуть не меньше, а теряется информация не только в результате пожаров.
Знаю не понаслышке, т.к. много лет помогаем с восстановлением данных с самых разных носителей.
Это да, но централизованное резервирование данных офисной инфраструктуры - более сложный вопрос, советы из статьи тут не помогут.
В скором времени всему земному шарику конец, а вы тут про какие-то бекапы.
Еще пункт забыли: если для вашего бизнеса железо - это дорого, а ваш бизнес не завязан непосредственно на обработку огромных массивов данных разных клиентов, то вы что-то делаете не так. У среднего екома пятилетней давности данных дай бог на 4-5Тб (скорее всего у 90% данных меньше 1Тб). Нагрузка на сервера прямо пропорциональна получаемой прибыли: больше трафика - больше денег.
В Германии в начале двухтысячных - была контора которая писала подобные этой статьи в бизнес газетах - перед тем как где-то начинался пожар в очередном бизнес центре, как бы намекая о том что что это с вами случится поэтому обращайтесь к нам и мы вам поможем. Говорят владелец этой конторы успешно сбежал с деньгами когда его начали искать. Есть есть слух что он в России где-то осел и собрал новую команду. Это я так ни к чему не веду ))) это же всё всего лишь страховые случаи правильно ? Обычные случайности с кем не бывает )
Блоги компаний
Комментарии
