Сейчас на целевой ИБ делается только полное копирование, делать на основной базе пока не хочу сделал себе копию, балуюсь на тестовой. Я в принципе уже настроил резервирование в соответствии с нужной мне моделью но есть неприятные критичные детали, которые я сделал как мне кажется немного костылем, поэтому дочитайте до конца хотя бы, чтобы своими советами не дублировать мои ранние действия.
Модель резервирования которую я организовал: 1 раз в месяц -полный, 1 раз в неделю в выходные - разностный(дифференциальный), с пн по пт, по времени выполнения каждые 30 минут с 09:00 по 18:00 - журналы транзакций.
Модель хранения которую я планирую ввести: полные - 6 за полгода от каждого месяца, дифы - 4 за последний месяц, журналы транзакций - все за последнюю неделю с пн по пт.
1) При тестировании когда я делал вручную в SSMS: полные, дифы и журналы, то они сохраняются в "наборе". В качестве теста вручную я делал следующее:
1 полный
1 диф
1 журнал
2 диф
2 журнал
3 журнал
При таком раскладе при восстановлении в наборе я перестаю видеть 1 диф и 1 журнал, в случае когда сделан 2 диф. Почему?
1а) Второй момент, с учетом того что оно всё ложится в набор, то при очистке полных или дифов они не различаются, почему? Я так предполагаю что с учетом того что и полный и диф имеют расширение bak они воспринимаются одинаково и каких либо "меток" для их различия я так понимаю нет? То есть если я в планах обслуживания на дифах сделаю очищать всё что раньше 4 недели, то у меня пропадут полные за предыдущие месяцы поскольку они в одной папке в одном наборе будут лежать с дифами.
2) Исходя из п.1 и 1а сделал 3 папки раздельно для полных, дифов, журналов. Каждый ложится в свое место как результат при очистке данных дифы будут очищать только свою папку, полные только свою в соответствии с планами обслуживания с помощью объекта "очистка после обслуживания". Первый костыль!
3) Исходя из п.2 делаю тестовое восстановление с устройства. На этапе восстановлении из полного делаю "перезаписать базу". С параметром для полного и дифа RESTORE WITH NONRECOVERY через раздел восстановления файлы и файловые группы.
Проблема конкретно с журналов начинается. При ручном режиме восстанавливать журналы по одному он дает понятное дело через файлы и файловые группы, но с учетом того что их будет очень много, если придется восстанавливать ближе к концу дня конца недели, то вручную восстанавливать по одному журналы заколебаться можно. При попытке восстановить группой журналы транзакций через файлы и файловые группы - ошибка, на скриншоте ниже.
По логике вещей как описано в документации и в интернете нужно восстанавливать через раздел восстановления журналы транзакций, так сначала и делал, потом уже баловался с "файлы файловые группы". При попытке восстановить через раздел восстановления журналы транзакций, он изначально был пусть, но я на этой базе туда сюда раза 3-5 постоянно восстанавливал и он таки запомнил мои восстановления слегка наизнанку. Сначала он увидел журнал, который делался до восстановления, потом собственно те журналы, которые я ранее восстанавливал по одному, сейчас да они видятся группой, но даже при этом они не восстанавливаются, скриншот ниже.
То есть если не играться с восстановлением, а в реальности на рабочей базе я дойду до момента восстановления журналов транзакций после полного и дифа, в разделе восстановления "журналы транзакций" будет пуст и придется восстанавливать по одному. Второй костыль!
4) Отдельный вопрос как рассчитывать размер резервных копий если для них еще не настраивалось резервирование, чтобы иметь представление какой винт под него выделить. Понятно что при данной модели вопрос встанет насколько сильно изменяются данные. Но если взять просто калькулятор и абстрактную ИБ то каков будет расчет, например база 70 ГБ, база изменяется в день скажем на 15%.
- Каков размер полной копии при таких данных при сжатии?
- Каков размер дифа?
- Каков размер журнала?
Мне кажется что расчет в лоб не получится, потому что я может упустил какие-то детали самого SQL SERVER'a?
4а) Второй момент как можно отследить насколько конкретно изменяется ИБ за день? Есть ли какой-то механизм чтобы это не проверять на глазок, мол, вот 15%, то есть не делать предварительно полный, диф, журнал а потом на коленках высчитывать нужный объем, а чтобы сам MSSQL выдал на сколько изменилась ИБ по сравнению с началом дня скажем?
Простой