Лучшая, на мой взгляд, логика бэкапов в Oracle (сравнивая нативный бэкапер Microsoft'a):
1) Есть дифференциальный инкрементальный бэкап со следующей логикой:
копия Level0 делается в Sun затем делаются инкременты на инкременты :) (Level1), в следующий Sunday делает опять копия Level0 со всеми изменениями за неделю. Т.е. копия Level0 это по сути Full-бэкап только его можно использовать в расписании инкрементов!! Это должно здорово уменьшать объем хранения резервных копий. Правда, это увеличивает время восстановления с резервной копии.
2) Есть кумулятивный инкрементальный бэкап с другой логикой:
В Sunday делаем бэкап Level0 (типа Full) и каждый последующий день к нему прибавляем инкремент, в следующий Synday опять делаем бэкап Level0 и процесс начинается сначала. В этой схеме время восстановления должно быть минимальным - ведь каждую резервную копию восстанавливаем из двух: требуемая дата+Sunday. Однако место должно быть побольше... Насколько больше? Для моего сервера это около 400-500 Мб в день... Журналы транзакций мать так их так :).
1) Есть дифференциальный инкрементальный бэкап со следующей логикой:
копия Level0 делается в Sun затем делаются инкременты на инкременты :) (Level1), в следующий Sunday делает опять копия Level0 со всеми изменениями за неделю. Т.е. копия Level0 это по сути Full-бэкап только его можно использовать в расписании инкрементов!! Это должно здорово уменьшать объем хранения резервных копий. Правда, это увеличивает время восстановления с резервной копии.
2) Есть кумулятивный инкрементальный бэкап с другой логикой:
В Sunday делаем бэкап Level0 (типа Full) и каждый последующий день к нему прибавляем инкремент, в следующий Synday опять делаем бэкап Level0 и процесс начинается сначала. В этой схеме время восстановления должно быть минимальным - ведь каждую резервную копию восстанавливаем из двух: требуемая дата+Sunday. Однако место должно быть побольше... Насколько больше? Для моего сервера это около 400-500 Мб в день... Журналы транзакций мать так их так :).
No comments:
Post a Comment