Частіше створюється резервне копіювання SQL БД

У мене зараз є планове завдання, яке вимикається щовечора о 2 ранку, яке викликає SQLCMD.exe і передає йому .sql-скрипт для запуску резервної копії (показано нижче). Ми досить невелика компанія з зростаючими потребами через значне зростання бізнесу. Втрата даних за один день в цей момент коштуватиме десятки тисяч доларів проти пари сотень цього разу минулого року. Поки я не зможу перенести цю платформу DB на інше рішення, де дзеркальне відображення даних відбувається з великими надмірностями, як SQL Azure, що найкраще, що я можу зробити, щоб отримати частіші резервні копії? Чи змушує цей скрипт нижче змушувати БД бути в автономному режимі? Чи можу я запустити цей скрипт із користувачами, які взаємодіють із БД?

USE CompanyCRM;
GO
BACKUP DATABASE CompanyCRM
TO DISK = 'D:\CRMBackups\CompanyCRMCRM.Bak'
   WITH FORMAT,
      MEDIANAME = 'CompanyCRM_Backup',
      NAME = 'Full Backup of CompanyCRM';
GO

Оновлення

Нічого собі, явно набагато більш віддане співтовариство DBA, ніж тут. Дякуємо за відгук. Єдине, чого не вистачає, - це "як". Я показав команду SQL вище, яку я використовую, щоб робити щоденні резервні копії, але приклади додаткового резервного копіювання журналу - MIA. Це не велика БД, вона зараз працює на SQLExpress. Коли я кажу HA або SQL Azure, я конкретно маю на увазі архітектуру, яку ми не маємо як малий бізнес. Цей екземпляр наразі працює на НАШОМУ сервері. Якщо цей сервер виходить з ладу, наш час відновлення стає крапкою. Ось чому SQL Azure стає привабливою.

РЕДАКТУВАТИ з вашого оновлення

Як ви вже говорили, що ви можете втратити дані на 1 день, то я б просто перевів бази даних у режим простого відновлення. Тоді ви могли зробити ПОЛІТНИЙ щоранку та / або ввечері. Якщо ви хотіли прикрити себе протягом дня, ви могли б провести різну резервну копію бази даних, одну з таких на всякий випадок. Це дозволить зафіксувати будь-які зміни, внесені після повної резервної копії. Якщо я знаю часові рамки, де відбувається багато вводу, я можу закинути цей тип резервної копії туди після її завершення. Це може заощадити людям час на відновлення, тому їм не доведеться робити додаткові дані.

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

Команда диференціального резервного копіювання:

USE CompanyCRM; 
GO 
BACKUP DATABASE CompanyCRM 
   TO DISK = 'D:\CRMBackups\CompanyCRMCRM_diff.Bak'    
WITH FORMAT, DIFFERENTIAL,
MEDIANAME = 'CompanyCRM_Backup',       
NAME = 'Full Backup of CompanyCRM'; 
GO 

• Резервні копії на SQL Server не порушують роботи. Тобто база даних залишається справною. Прочитайте документацію.
• Робіть повне резервне копіювання кожного дня, після чого відправляйте (скопіюйте) резервні копії LOG (знову ж таки, у документації є ... документація) більш регулярно - як кожні 15 хвилин.

Перше, що вам потрібно зробити - це зрозуміти, скільки даних ви можете собі дозволити втратити. До цього часу ви не знаєте, як часто робити резервну копію бази даних. Це не число, яке вам слід придумати. Це щось, про що мав би вирішити бізнес (або генеральний директор у меншій компанії). Перше число, з яким вони збираються повернутися, - це 0 хвилин. Що можна зробити, але зробити це буде дуже дорого. Насправді найменший обсяг даних, за який можна зробити резервне копіювання, - це приблизно кожні 2 хвилини. Якщо кількість даних, що змінюються в системі, досить мала, ви можете робити резервні копії щохвилини.

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

Якщо ви можете дозволити собі втратити дані на 5 хвилин, то, ймовірно, ви хочете робити щоденні резервні копії та робити резервні копії журналу транзакцій кожні 5 хвилин. Якщо ви можете втратити дані на 15 хвилин, тоді вам потрібно буде робити резервні копії та резервні копії журналу транзакцій кожні 15 хвилин.

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

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

Усі резервні копії, які використовують базу даних BACKUP та оператор BACKUP LOG, здійснюються в Інтернеті і не заважають користувачам отримувати доступ до бази даних.

Скажімо, у вас є спільний сценарій ділових ситуацій з найжвавішим часом роботи: 9:00 до 17:00 понеділок-п’ятниця. Тоді я б запропонував: Повне резервне копіювання в ніч на неділю. Диференціальні резервні копії о 8 ранку, 6 вечора та 1 ранку (щоб скоротити час відновлення). Реєструйте резервні копії щогодини або залежно від необхідності вашого бізнесу.

Залежно від терміну зберігання, вам слід мати автоматичну роботу з очищення, щоб очистити старі файли резервної копії. Все це можна створити за допомогою планів обслуговування SQL. Перевірте це посилання на SQL 2005 .

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

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

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

Чи скрипт принаймні розміщує копію резервної копії в мережі? Таким чином, якщо фізична скринька підірветься ...