Техники садомазоразраба или вредные IT советы
Знакомые прислали
Знакомые прислали
Админы обычно делятся на 3 категории:
1. Не делают бэкапы.
2. Уже делают бэкапы.
3. Уже проверяют сделанные бэкапы.
Мне больше нравится другая шутка. Админы делятся на 2 типа: на тех, кто делает бекапы, и на тех, кто УЖЕ делает бекапы.
но это же логически не верно: УЖЕ делает бекапы только тот, кто до этого не делал и напоролся, но мы эту группу исключили, хотя в контексте она присутсвует. Шутка должна быть примерна такая:
"Админы делятся на тех, кто не делает бекапы, тех кто делает бекапы, и на тех, кто УЖЕ делает бекапы."
Ага.. правда не проверил работали ли те бэкапы.. Сам так один раз сделал. Хорошо, что потом изменил систему и уже были другие.
Не люблю бэкапы, с ними ощущения "не те".
Да и, к тому же, бэкапы только для неуверенных в себе.
Чет тоже не понятно. Бэкапы делаются постоянно, их всех не проверишь. Или имеется ввиду проверять делаются они или нет?
Хотя бы раз, а лучше периодически необходимо проверять, можно ли восстановить из бекапов всё, что нужно. Обычно это делается в тестовой среде. Иначе может оказаться, что бекапы формально делаются, но неправильно (например включена не вся информация) или не могут быть восстановлены и фактически бекапов нет.
Это все в теории. В реальности никто этого не делает, когда объемы бэкапа исчисляются десятками терабайт. Максимум - встроенная проверка целостности в самой системе бэкапа.
Десятки терабайт - копейки в наше время! Большие данные можно бекапить частями... Многие системы позволяют делать частичное восстановление...
Ещё раз повторю: не проверять бекапы - опасно! Те, кто этого не делают рискуют.
Veeam умеет поднимать аж целое тестовое окружение, при необходимости. Veeam SureBackup называется, емнип.
Проблема в ресурсах для этого окружения и в корректной проверке. Как ты проверишь бэкап AD? А пассивные реплики тоже проверять? А главное от чего проверять? На предмет багов в софте бэкапа? Техническая проверка также проходит автоматически да и также в основном бессмысленна т.к. при работоспособном массиве логические ошибки исключены. А какие угрозы мы восстанавливая 10ТБ мелких файлов? Что, есть вероятность что бэкап, прошедший техническую проверку окажется битым?
Легко. Поднимается изолированная лаба со всей инфраструктурой, и проверяется работоспособность. В том числе, при необходимости, скриптами. У той же AD есть вполне себе встроенные средства контроля, например.
Но, в данном случае, даже проверка запускаемости - это уже полдела. Потому что ты хотя бы будешь знать, что твой последний бэкап - хотя бы минимально работоспособный.
А на счет работоспособного массива, тут есть свои нюансы. Во первых, контроллеры порой могут глючить. Например, у меня был случай, когда на одном из третьестепенных серверов контроллер говорил, что с целостностью RAID все в порядке. Но OS не грузилась. Один из дисков просто посыпался, в то время как второй был жив.
Да и зачем восстанавливать данные на файловом уровне? Когда можно, например, развенуть ВМ целиком?
Шансы на то, что бэкап прошедший проверку, окажется битым - не велики, но безусловно присутстсвуют. Но, они априори ниже, чем шансы оказаться битым у непрошедшего проверку архива.
Неверно. Правильно: бэкап находится в состоянии суперпозиции: он одновременно есть и его нет, до тех пор пока ты его не попробуешь загрузить
Или тупо в непонятном формате каком-то забекапилось. Особенно если это БД, там много тонкостей. В итоге если ты не знаешь как ТОЧНО восстанавливаться из бекапа, то это займет очень много времени, а то и вообще выяснится что ты что-то критичное забыл. Так что ечли нет тестирования восстановления из бекапа - считай что нет бекапа.
Развернуть на тестовый/резервный сервер и сравнить?
Ну ели кратко, то должно быть понимание и план что делать если основной сервер накроется. Например, если произойдет пожар/потоп.
Бывают люди, которые вместо файла на флэшку ярлыки скидывают, а ещё те, которые открывают архив, запускают оттуда файл на редактирование, редактируют и сохраняют в тот же TEMP. Но мы ведь не как они, у нас ведь всё корректно и продумано.
у клиентов был админ, который точно так же был уверен что у него есть бекапы и тд, делаются автоматически (это все сделал еще прошлый админ, а новый проверил все збс). а когда понадобился бекап, оказалось что последний был полтора года назад ибо место на жестком закончилось пара-пара-пам-пам.
Мониторить расход пространства? Настроить автоматическое удаление очень старых бэкапов? Не, и так сойдёт.
Если у тебя мусорка заполняется, то ты же её выносишь? Если у тебя настроен автоматический выносчик мусора, то и мониторить не надо, но только если у тебя настроен оповещатель на случай если хотя бы хард накроется.
Но если неправильно настроить выносчика мусора, например, выносить всё, что старше месяца и у тебя дата случайно слетит, то выносчик вынесет абсолютно всё. Админ либо грамотно настраивает, либо постоянно всё мониторит. Хотя, лучше создавать себе поле для деятельности, чтобы её имитировать.
Меняются права на сетевую шару, куда льются бэкапы, например. Меняется пароль от учетки, которая делает их. Кто-то удалил в планировщике задание. Да мало ли причин может быть.
По этому, принято проверять работоспособность бэкапов. Вон, тот же Veeam, при наличии соответствующей лицензии, умеет поднимать и тестировать целое тестовое окружение, для проверки работы забэкапленного.
Какая сука поменяла пути и разрешения и удалила задание? Тут уже саботаж. Найти эту суку, оторвать передние лапы и пришить на место задних. Проверять работоспособность бэкапов в ряде случаев может быть очень накладно.
Найти эту суку, оторвать передние лапы и пришить на место задних.
Это будет потом. Но сначала с тобой сделают это:
В компании, в которой я сейчас работаю, больше 200 человек в ИТ отделе. В подобном случае - виновного найдут, но стоимость простоя может быть такой, что даже если разобрать на органы все семейство такого работничка, то и это не окупит ущерба.
Если у тебя прямой архив - хотя бы смотреть заархивировалось ли. А то архив 100Гб данных может весить 2Кб. В котором будет сообщение что архивирование прервано.
IT-юмор
5.6K постов52.5K подписчик
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору