LINUX.ORG.RU
ФорумTalks

Более правильные бэкапы

 , ,


0

1

Привет, лорчан.

Мы с коллегой разделились во мнениях, когда настраивали бэкапы MSSQL (собственно поэтому в толксы).
Вот есть два стула подхода:

  • Вариант коллеги: Full backup ежедневно; diff ежечасно; журнал не трогаем, ждём пока совсем раздует, затем думаем. Планировщик сторонний (nnBackup), отчёты не завезли. Объём архива за 4 дня: 200 гигабайт.
  • Мой вариант: Full backup еженедельно; diff и журнал ежедневно. Всё средствами Maintenance Plan, включая отчёты о проделанной работе. Объём архива за неделю: 15 гигабайт.


Все базы с Recovery model: Full, прочие условия считаем равными.

Мой вариант был заклеймён позором, т.к. есть риск потери информации при повреждении промежуточного диффа. При этом я почти не имею опыта работы с MSSQL, коллега же работает с ним довольно давно. Настраивал по рекомендациям с TechNet/ServerFault после того, как бэкапы коллеги засрали под завязку раздел с базами, а я случайно заметил.

Объясните почему мы оба не правы и как надо было делать.

P.S. Кстати, как поживает это болото? Полгода не был здесь.

Deleted
Ответ на: комментарий от Gotf

Ну просто гуру юмора. Так тонко и неожиданно.

Deleted
()

у нас практически второй вариант, как для mssql так и для oracle - full раз в неделю, инкрементальный каждый день, журналы/архивлоги - каждый час-два в зависимости от нагрузки сервера. Все средствами netbackup.

За много лет ни на одном из серверов (всего около 120 баз) потерь не было, максимум - практически забитый раздел с журналами и срочный ручной запуск заданий, ну и несколько остановок базы когда на отбивки о непрошедшем бэкапе журналов все забивали. Журналы на бэкапятся на диски, потом большой пачкой сбрасываются на ленты, полный и дифф сразу на ленты

user_undefined
()

Понятия не имею что там в оффтопsql, но по принципу бекапирования я склоняюсь к варианту твоего коллеги.

Или у вас жуткий дефицит места для бекапов?

dvrts ★★★
()
Ответ на: комментарий от dvrts

Нифига не толсто. Я хочу знать, почему надо сознательно забивать на журнал и делать его подобие при помощи диффов? Это что-то типа народных рецептов по размещению свопа на рам-диске?

Deleted
()

А зачем вам backup?

uspen ★★★★★
()

Объясните почему мы оба не правы

Потому, что чайники. А скорей даже кофейники.

и как надо было делать.

Сначала определить окно восстановления (срок, на который может потребоваться откат).

Затем определить максимальный лимит времени восстановления (сколько минут/часов/дней можно заниматься восстановлением).

Затем определить допустимое окно потерь (сколько зафиксированных транзакций допустимо потерять в процессе восстановления).

Определить размер данных и размер дельты за время окна восстановления (сколько данных может поменяться за указанное время).

В конечном итоге, вы придете к Full (он же L0) раз в неделю, L1 ежедневно + журналы ежечасно; и будете хранить 2xFull, 14xL1 и 14*24 журналов.

no-dashi ★★★★★
()
Ответ на: комментарий от dvrts

Гиперотличное решение

Своп в оперативе - отличное решение!

А как вам пожатый (gzip) своп в оперативе?

Camel ★★★★★
()

Фуллбекап ежедневно + репликация две железки в разных концах мира.

alexmaru
()

diff ежечасно

Расскажи своему наркоману про репликацию.

entefeed ☆☆☆
()

Я в mssql ничего не понимаю, но... нельзя ли тупо сделать синхронную репликацию? Тогда есть шанс что при отказе одного сервера ничего вообще не потеряется.

Ну и фулл раз в день (или чаще) на случай совсем полного ппц-а.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Ой, с репликацией я тут не один такой умный....

true_admin ★★★★★
()

А про различие полного, дифференциального и инкрементного бэкапа вам объясняли? В теории, дифф должен делаться с опорой только на полный, а инк - с опорой на всё подряд.

om-nom-nimouse ★★
()

офтопъ

давно тебя не слышно было. как сам? где сейчас? (если не секрет)

ZuBB ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.