Чим резервні копії SQL відрізняються від регулярних резервних копій на серверах ІТ-систем?

Наш ІТ-відділ щовечора створює резервні копії всього сервера (на цьому сервері встановлений екземпляр SQL Server), який повинен створювати резервну копію цього сервера, а також всієї мережі, на випадок, якщо щось піде не так ...

Тож мій менеджер запитав, що є значущим для моїх резервних копій Full, Differential і Log SQL порівняно з тим, що резервне копіювання IT-відділу? Щоб заощадити більше місця на нашому сервері, а не зберігати ці файли протягом декількох тижнів і видаляти їх, вона вважає, що ІТ просто забезпечить їх!

Я знаю, що це неправильно, оскільки я можу відновити до останніх 30 хвилин за допомогою резервного копіювання журналу, ІТ відновить його на наступний день, але чи це єдина різниця?

Оскільки я зберігаю / надсилаю файли резервного копіювання бази даних на один і той же сервер, ІТ відновить їх, але якщо я не маю цих завдань резервного копіювання в моєму плані обслуговування, то ІТ може просто відновити екземпляр SQL без будь-якої з наших таблиць, транзакцій ... та ін. Чи правильно я це розумію?
Будь-яка порада буде дуже вдячна.

Резервне копіювання бази даних дає змогу відновити момент часу (за умови, що у вас є FULLмодель відновлення). Навіть якщо ваші ІТ-люди роблять резервні копії кожні кілька хвилин, що вкрай малоймовірно, у вас все одно буде розрив.

Резервні копії сервера не замінюють резервні копії баз даних, вони доповнюють їх, "архівуючи" файли резервного копіювання бази даних довгостроково (тобто більше, ніж просто сьогодні).

Зрештою, ви та ваше керівництво повинні вирішити свій RPO (мета точки відновлення - скільки потрібно, щоб мати змогу відновитись після аварії). Маючи лише щоденні резервні копії сервера та відсутність резервних копій баз даних, ви в гіршому випадку втрачаєте роботу цілого дня.

Редагувати : @Sting має дійсну точку в тому, що тіньові копії (механізм, який, швидше за все, використовується для створення резервних копій сервера), малоймовірно, будуть робити одночасно копію всіх файлів вашої бази даних (включаючи файли журналів), що може призвести до невідповідностей, коли ви відновите резервну копію. Наприклад, якщо тіньова копія читає журнал транзакцій за кілька мілісекунд до того, як він зчитує файл бази даних, файл бази даних може містити невиправлену транзакцію, але оскільки транзакція була здійснена пізніше мілісекунди, журнал не матиме жодного запису про неї.

Є ймовірність, що відновлення файлів mdf та ldf із тіньової копії буде транзакційно непослідовним. Це означає, що ці тіньові відновлення не відповідають властивостям ACID бази даних.

https://msdn.microsoft.com/en-us/library/aa480356.aspx

Швидше за все, відновлення, ймовірно, спрацює, але вам залишиться цікаво, що ви насправді отримуєте. (Не кажучи вже про те, що вам потрібно буде тестувати, щоб переконатися, що резервні копії / тіньові копії сервера працюють належним чином на кожному сервері). Крім того, немає можливості відновити журнали транзакцій до певного часу, як можна за допомогою SQL Server T -SQL RESTORE LOG / STOPAT.

Поки резервні копії / відновлення Windows Server не відповідають тесту ACID SQL Server, наша галузь не може дозволити собі ризикувати.

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

Все залежить від того, який продукт використовує ваш ІТ-відділ для резервного копіювання на сервері.

Наприклад, у віртуальному середовищі VMWare зробить знімки сервера. Якщо задіяний SQL Server, VMWare має можливість включення більшості адміністраторів (або це може бути за замовчуванням, я не знаю), що заморозить IO для баз даних під час знімка. Тепер, хоча це має зайняти лише кілька секунд, у вас є потенціал, який може викликати проблеми у вашій програмі, і це насправді не є надійним методом використання для відновлення бази даних.

Якщо ви використовуєте сторонній продукт для створення резервного копіювання на сервері, то ймовірність цього полягає лише в тому, щоб зробити резервні копії на рівні файлів ваших баз даних. Крім того, він повинен мати можливість робити резервні копії файлів, які заблоковані, оскільки SQL Server має будь-які додані файли mdf та ldf, заблоковані з точки зору Windows. Наприклад, BackupExec Symantec використовує розширений варіант відкритого файлу, щоб виконати це, так що в основному він може сфотографувати цей заблокований файл. Точно так, як це звучить, змусить більшість DBA переслідувати, якщо доведеться відновлювати базу даних із такою резервною копією, подумайте про узгодженість бази даних, коли вона бере цю резервну копію. Немає гарантії, якщо резервна копія запускається, коли відбувається процес завантаження даних, яку частину завантаження даних отримала ця резервна копія?

Народні резервні копії SQL Server заслуговують на довіру до поваги, яку вони перевіряють як хороші резервні копії. Ви точно знаєте, в якому стані вони знаходилися, коли ви запускали резервну копію для ПОВНОГО, чи є у вас заплановані дані щодо завантаження даних тощо. Резервне копіювання журналу для повних гарантованих моделей відновлення ви можете відновити цю базу даних другою.

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

Що також слід врахувати та обговорити з вашим менеджером - те, яку участь вам доведеться мати у підтвердженні та усуненні несправностей, якщо резервні копії SQL Server не вдається. Я багато використовував Netbackup на попередніх роботах, і клієнт кілька років тому хотів, щоб я пройшов тестування використання агента SQL Server Netbackup для свого оточення. Сюди входили й інші DBA, які також мали надати підтримку. Я сказав їм заздалегідь, що для усунення несправностей відмов резервного копіювання для SQL Server потрібно, щоб ви добре знали про Netbackup. Основні сервери Netbackup зазвичай працюють на серверах Unix, тому тепер вам доведеться знати деякі Unix .... може бути цікаво, але більше, якщо ви вже зайняті. Просто щось, що варто врахувати, і може стати гарним питанням для обговорення з вашим менеджером та дізнатися, хто несе відповідальність за усунення несправностей.

У вашому запитанні трохи менше мільйона змінних. Вам потрібно буде поговорити зі своїм ІТ-відділом про те, які резервні копії вони беруть. Ймовірно, вони мають або можуть мати до хвилини резервні копії. Скільки часу потрібно для їх завантаження, залежить від більшої кількості змінних.

У ідеальному випадку ваш ІТ-відділ зберігає ваші резервні копії на одному або декількох різних серверах у різних місцях. Ви, ймовірно, зберігаєте резервну копію на тому самому сервері, на якому базуються ваші бази даних. Тож якщо сервер загине або ваша будівля згоряє, ваш ІТ-відділ, ймовірно, може відновити ваші файли, але резервні копії, які ви зробили, не будуть використані разом із сервером.

Але ви можете відновити резервну копію зі своєю швидкістю, коли хочете, за умови, що ваш сервер ще живий.

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