Який хороший графік резервного копіювання на SQL Server?

Здається, є безліч інформації щодо процесу налаштування завдань резервного копіювання, але не так багато інформації про велику картину резервного копіювання бази даних. Принаймні, важко сформулювати запит пошукової системи, який дає вам цю інформацію. Я знаю, що існує три різних типи резервного копіювання:

• Повне резервне копіювання баз даних
• Диференціальні резервні копії баз даних
• Резервні копії журналу транзакцій

Здається, я повинен використати всі три. Отже, чи є такий графік, який має сенс?

• 1-го числа кожного місяця - Робіть повне резервне копіювання бази даних
• Кожен день опівночі - робіть диференційоване резервне копіювання.
• Кожні 15 хвилин - робітьрезервну копію журналу транзакцій .

Таким чином, якщо моя база даних не працює, скажімо, 12-го, я б просто відновив повне резервне копіювання бази даних з 1-го, зробив 12 диференціальних резервних копій з 1-го по 12-е, а потім нарешті відновив останній журнал транзакцій (є диференціальний журнал транзакцій?).

Нарешті, чи є резервна копія повної бази даних самостійною? тобто, коли я 1 лютого я роблю повне резервне копіювання бази даних, чи можна видалити всі файли з січня? Звичайно, я хотів би зберегти пару попередніх місяців на всякий випадок, але питання концептуальне.

Як і у всіх речах на SQL Server, це залежить.

Перше, що вам потрібно зробити, це переконатися, що ви розумієте, що робить кожен тип резервної копії.

Книги в Інтернеті містять усі деталі Google , але ось мій підсумок.

Повна резервна копія містить усе, що знаходиться в базі даних. ДИФФЕРЕНЦІАЛЬНА резервна копія НЕ наростає. У вашому прикладі, якщо ваша база даних не вдалася 12-го числа, вам потрібно було б відновити повну резервну копію з першого, а потім останнього диференціалу на 12-й, а потім слідувати всі резервні копії журналу транзакцій до помилки. Резервна копія журналу TRANSACTION LOG потрібна лише для баз даних, що використовують модель відновлення з повним або об'ємним журналом. Якщо ви використовуєте просту модель відновлення, тоді резервні копії журналу транзакцій не потрібні.

Тепер, коли ми це розібрали ... Розробка розкладу резервного копіювання дійсно залежить від того, скільки даних потрібно для відновлення та як швидко потрібно відновити їх у разі виникнення діастерії. Я б рекомендував починати з повного резервного копіювання кожного дня. Ви завжди можете зменшити частоту пізніше. Пам'ятайте, що диференціальне резервне копіювання є кумулятивним з моменту останнього повного, тому залежно від зміни суми, що відбувається у вашій базі даних, диференціал може бути більшим, ніж повне резервне копіювання через кілька днів. Якщо ви робите повне резервне копіювання кожного дня, можливо, вам не потрібно буде використовувати диференціали взагалі; однак ви все одно можете це робити раз на день і планувати це на 12 полудня. Резервне копіювання журналу транзакцій створює резервну копію лише журналу. Частота резервного копіювання журналу визначає, скільки даних ви готові втратити у разі відмови. Якщо ви робите резервну копію журналу кожні 15 хвилин, то ви очікували втрати останніх 15 хвилин даних, які змінилися. 15 хвилин - це хороша частота, але кожні 30 хвилин ідеально підходить для мого середовища.

Як я вже говорив раніше, все залежить від вашого оточення. Після того як ви розробили та налаштували розклад резервного копіювання, не забудьте перевірити його на альтернативному сервері. Практикуйте відновити ваші резервні копії повного, розрізнення та журналу, щоб ви знали, що все працює так, як ви його спроектували.

Книги в Інтернеті мають хорошу інформацію, якщо ви плануєте використовувати Плани технічного обслуговування, але якщо ви дійсно хочете гнучкості, ознайомтесь із резервними сценаріями Ola Hallengren .