Комментарии 14
Помню, как зашел на позицию CIO на некое предприятие.
- бэкапы делаете?
- а как же.
- где они у вас?
- вот они, тут.
- а восстанавливаться с них пробовали?
- а зачем, пока, слава богу, ничего не падало.
- ....
Пришлось объявлять в выходной учения по восстановлению данных из бэкапов. Выяснилось много интересного, технологию резервного копирования пришлось существенно менять.
Через 15 лет призвали поднимать из руин драматически рухнувший интернет проект. Один админ сбежал еще до меня, второй за один день показал мне дым пожарищ и сбежал тоже. Техдир, который все это допустил, дорабатывал последние дни и нужен был только для инвентаризации железа. Так вот, там бэкапы делали в Bacula. В основе оной была MySQL-база. Она рухнула одной из первых. То, чем потом пришлось заниматься, чтобы выгрызть хоть какие-то куски проектов из разрозненных останков Бакулы, напоминало чистку септика на даче с выгребанием говна своими руками при помощи ведра.
Так что совет один - бэкапить надо тем, из чего потом точно сможете поднять. Для данных в идеале это rsync. Загрузочные диски желательно зеркалировать, профит может оказаться несоизмеримым с расходами. То, что может жить в контейнерах типа jail или lxc, надо там и держать, регулярно снимая снапшоты. СУБД - дампы, дампы и еще раз дампы. Если сподобились поднять репликацию на резервный сервер, то обязательно учения по переключению на резервный сервер и возврату на основной.
Понятное дело, для серьезных корпоративных проектов с мегабюджетами, где техдиры, девопсы и тимлиды с утра до вечера пишут планы и отчеты рабочих групп, есть соответствующие инструменты, учитывающие в полной мере требования корпоративной бюрократии и позволяющие не ударить носом в грязь перед аудиторами. Но мы же не о них? )))
Да, бекапом можно считать то что можно восстановить. И я не часто, раз в полгода провожу, тестовое восстановление на виртуальную машину разные сервера. Только у меня бекапы без подписи, что тоже не гуд совсем. Так злодей может подменить архив.
Рисковый вы человек. Восстанавливаете раз в полгода. Я каждый бэкап через некоторое время проверяю на восстановление. Что вы будете делать, если в очередную проверку окажется, что восстановиться может только бэкап пятимесячной давности? Если он вообще будет существовать.
У каждого своя ситуация. Например сервер Elastix, или OpenVPN меняются крайне редко и имея все данные по изменением (телефонные номера, SIP аккаунты) можно восстановить и старую версию. Есть важный файловый сервер, с ним проще - очень часто просят восстановить тот или иной файл. Получается неполная проверка файлового архива. AD - тут три домен контролера, мало вероятно что все три одновременно накроются по естественным причинам. Важный сервер 1С - тут всё хуже, база всегда есть в архиве с большой глубиной. Только восстановление займет очень много времени так как восстанавливать не на что, нужен сервер такой же по характеристикам или лучше. И так далее. Риск конечно есть, еще конечно я запускаю тестирование архива программой которая делает архив, но и тут риск есть.
На файловом сервере часто просят восстановить старую версию того или иного файла, так что версии за разумное время хранить крайне желательно. Тоже самое с 1С, бухгалтерам часто приходит на ум менять что-то задним числом, что вроде как нельзя, но если очень хочется, то деваться некуда. AD - отдельная песня. Не знаю, как в последних версиях, но во времена W2K3 адэшка могла просто развалиться, Primary отцеплялся от Secondary, и в некоторых случаях помогал только синхронный откат всех DC, хотя иногда удавалось связать домен-контроллеры при помощи шаманства в командной строке.
Спасибо за такую интересную историю, сравнение с чисткой септика очень жизненное)) Вы правы, проверять работоспособность резервных копий — крайне важная итерация. Напомнило историю отсюда :)
Просто надо использовать нормальные инструменты. Бакура к таким не относится.
Не изучен вопрос - после удачной попытки тестового восстановления не уменьшается ли надежность самого бэкапа и гарантирована ли повторная попытка восстановления. Может быть эта тестовая удачная и была единственной удачной, которая и нужна бы была для реального восстановления.
ответственность за сохранность данных и их бэкапов можно передать провайдеру
А у провайдера случился пожар/потоп/налетсаранчи, и он такой: "все ваши данные потеряны, вот вам 30 дней бесплатного облака в виде компенсации"
Воспользоваться ими можно с 1 по 28 февраля 2050 года по будням с 8 до 17
Конечно, какой бы надежной ни была инфраструктура, всегда есть вероятность возникновения нештатных ситуаций, способных негативно повлиять на работу компании в целом. Но дата-центры как раз и служат решением, которое закрывает потребность в отказоустойчивости и надежности.
Например, для защиты серверных и технологических помещений в своих дата-центрах мы используем самые проверенные средства пожарной защиты, не экономя на надежности инфраструктуры и качества ОТВ. Высокий уровень защиты достигается за счет использования автономных центральных станций газового пожаротушения с веществом Хладон 125. И это только про системы пожаротушения.
А что касаемо сохранности бэкапов — мы также предлагаем инструменты, которые позволяют делать резервное копирование по правилу 3-2-1.
Но дата-центры как раз и служат решением, которое закрывает потребность в отказоустойчивости и надежности.
ДЦ как и любой бизнес служит извлечению прибыли. А все остальное это скорее проблемы клиента. Который проверить актуальность всех описанных мер безопасности не в состоянии. Что вполне логично, эти меры, будучи исключительно затратами для ДЦ — деградируют.
На выходе мы получаем
https://www.gazeta.ru/tech/2021/03/11/13507844/tsod.shtml
где здание выгорает полностью, система пожаротушения что-то ничего не потушила, персонал с пожаром бороться не умеет, а приехавшие пожарные длительное время даже не могут обесточить здание.
Но при этом до последнего верим, что там-то все надежно и продуманно. Я бы сказал, что там черный ящик. И цели у этого черного ящика сильно расходятся с целями клиента.
можно настроить восстановление файлов и отдельных дисков, объектов приложений SQL Server и Oracle
А восстановление на уровне БД точно будет работать из EM сервис провайдера? Если я правильно помню, виму нужен прямой сетевой доступ для такого манёвра. Есть настолько смелые провайдеры?
Добрый день! Да, всем данная возможность из коробки не доступна, но мы делаем схему под запрос клиента. Она разработана для организации восстановления отдельных БД MSSQL на уровне приложения из image based резервных копий, созданных в рамках резервного копирования облака на базе VMware. Ставим специализированные guest interaction proxy (GIP), через который возможен доступ по сети к инфраструктуре.
Правильные и простые бэкапы. Инструменты Veeam для резервного копирования — в чем разница?