Простой план сохранения онлайн-бизнеса при пожаре в дата-центре

[osipov_dv]

Самый главный совет не дали — храните бэкапы офлайн, офсайт в специальном месте (хотя бы в несгораемом шкафу).

[denaspireone]

2n+1 места и будет радость, главное не дома на nas

[nochkin]

Что не так с NAS'ом? Особенно если это просто одна из копий, а не единственная.

[swanrnd]

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

Это защитит от взлома, вирусов, шифровальщиков, утечек и так далее.

Основная мысль:
Бекап сервер должен подсоединиться к серверу БД, а не наоборот.

[mSnus]

Может быть, посоветуете какой-то готовый инструмент для этого? Чтобы скачивал, тестировал целостность, оповещал, если что-то не так...? Совсем идеально было бы раз в месяц автоматом запускать бекап и проверять чем-то Selenium-подобным, но это уже мои мечты)

[nochkin]

Если есть инструменты «чем-то Selenium-подобным» уже, то можно ими же воспользоваться и для проверки бекапов.
А скачивание и прочее уже сильно зависит от самих данных.

[pureacetone]

Кустарный способ для малых проектов собственного использования:
На основном сервере раз в сутки создается архив с критической информацией, шифруется GPG. Через Nginx файл доступен через веб по некоему URL а-ля /secret-folder/ha/br/backup$(date -d "$date -1 days" +"%F").tar.gz.gpg с допуском только с определенным user-agent. Также используется нестандартное значение вроде "itsmebaby".

На резервной VPS с бэкапами не нужно хранить какие-либо ssh-ключи и прочее, а всего лишь положить простенький bash-скрипт в cron.daily. Доступ к скаченным бэкапам можно открыть через FTP или вовсе через Nginx, позволяя скачать в обычном браузере.

Использование GPG лишает схему критических уязвимостей утечки.

[saipr]

Был и такой пожар:

С бэкап-ом всё было нормально. Проблемы были с восстановлением интернета.

[AlexGluck]

Если бы вам действительно надо было, вы бы давно решили вопрос резервирования. Во первых можно работать дистанционно, во вторых есть (и был) скоростной 4G (помимо 2х проводных провайдеров). А цена вопроса рублей 400 на канал и по 2000 на железки. Как по мне, глупость и жадность, наконец то получили по заслугам.

[saipr]

Откудово вы знаете про глупость и жадность?! По кому судите?
По заслугам говорите…

[AlexGluck]

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

Для SMB решения можно взять SOHO маршрутизатор с USB, купить 4G модем и настроить на openwrt multiwan решения. Для телефонии манго это неплохо, но резерв в виде sipnet тоже можно подключить.
При этом сипнет будет стоить 5 долларов в год, железо 130-150 долларов, а вот работа всегда была дорогой.

[sunbeam]

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

[AlexGur]

Стоит хранить одну из зашифрованных (через gpg) копий у себя дома, на hdd, подключенном к Raspberry Pi. Сама малина должна по расписанию скачивать подготовленные копии с удалённого сервера. Как показала практика, получается дёшево и эффективно.

[svitoglad]

Храните биткоины в СберБанке, если они у вас есть. :)

[Shiover]

Интересней другое. Что европейские компании скрыли этим ЧП. какие махинации. Один из крупнейших ЦОД и без системы пожаротушения — это как минимум заставляет задуматься о чистоплотности.