We rise up for the things we believe in over and over again
Недавно я отмечал, что DPM - синоним слова "проблема". Лишний раз убедился в этом, только на этот раз в связке с серверами SQL. Бекапить SQL-базы можно по-разному. Можно сделать полный бекап всего, и делать его раз за разом. Долго, много места. Можно делать полный бекап, а за ним цепочку инкрементов. По времени будет гораздо эффективнее, хотя процедура восстановления будет слегка сложнее, чем просто развернуть полный бекап. Запись немного о другом.
Мониторинг выкинул предупреждение - на SQL-сервере на системном диске кончается место. Посмотрели, реально заканчивается, 15% от всей емкости. При этом ничего нового на серваки не ставилось. Ок, windirstat в зубы и смотрим, куда место ушло. А ушло оно под базу данных. Оставлю вопрос о том, почему база была на системном разделе (сам прекрасно знаю, что так не делается). Смотрим, что там место скушало. Оказалось, распух ldf-файл. Но позвольте, у нас же бекапы настроены. Каждый день эти базы бекапятся, и без ошибок. Значит, логи должы были отсекаться.
И вот тут на сцену выходит DPM:
В терминологии DPM синхронизация - это и есть инкрементальный бекап, во время которого отсекается журнал транзакций. Любой, повторюсь, любой админ настройки синхронизации в этом окне читает следующим образом: мне дают выбор - делать инкрементальный бекап через равные промежутки времени, либо делать каждый раз прямо перед снятием полного бекапа (которым является Express Full Backup, но это в приближенном виде, на практике чуть сложнее). И проблема в том, что на самом деле работает все не так! Ни в одном абзаце документации по DPM не сказано, что если выбрать в данных настройках значение Just before recovery point, DPM не будет делать бекап логов транзакций. Вместо этого он стащит с сервера SQL изменившиеся блоки в файле самой БД, сольет их с репликой на сервере DPM, после чего на основе получившихся данных сделает очередную точку восстановления. Хотите нормальные инкрементальные бекапы - ставьте регулярную синхронизацию через определенные интервалы времени, это единственный вариант.
В сухом остатке проблему с распухшими логами решили так. Сняли полный бекап базы (бекапов много не бывает), затем саму базу перевели на использование модели восстановления Simple. Затем штатная операция Shrink на файле журналов, который тут же ужался до каких-то 4-5 мегабайт. После чего база снова переводится на обычную для нее модель восстановления Full, а в настройках DPM создается новая группа защиты, в которой указана синхронизация каждые 2 часа. После этого создается новая реплика базы, по расписанию проходит синхронизация логов, и вуаля - мониторинг радостно верещит, что проблем с местом больше нет. Ну и в идеале надо бы запланировать перенос базы на другой раздел. Негоже данным болтаться на системном диске.
Уважаемые сотрудники компании MS (хотя что это я, уважением там давно уже не пахнет). До каких пор вы будете плодить в своем хваленом ПО настолько обидные косяки, что просто диву даешься, как ЭТО проходит какой-либо контроль качества. Да ладно, я задам другой вопрос - у вас в принципе QA еще осталось хоть в каком-то виде? Или ваши пресловутые эффективные манагеры разогнали эти отделы окончательно? Вашу же гребаную американскую мать, одумайтесь!