Мені потрібно створити резервну копію 10-20 баз даних SQL Server 2008 R2 розмірами від 10-50 ГБ, при цьому вони є в Інтернеті та використовуються одночасно одним корпоративним додатком. Мені також потрібно відновити їх до стану, який значною мірою синхронізується у всіх базах даних (я можу дозволити до декількох секунд десинхронізації між базами даних). Метою є збирання виробничих даних для середовищ QA / DEV.

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

Для моїх клієнтів знадобиться 1-2 години, щоб отримати 20 повних резервних копій на ~ 30 ГБ кожен. Це робить послідовне завантаження резервних копій неприйнятним, оскільки бази даних будуть занадто десинхронізовані при запуску у простому відновленні.

Я шукаю ідею краще за ці:

IDEA 1: Знімок на рівні SAN на VM дисках. xcopy MDFs / LDFs зі знімка.

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

IDEA 2: Оркеструйте складне резервне копіювання та відновлення синхронізації у всіх базах даних

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

Я пропускаю якесь інше рішення?

PS1: Мені б хотілося використовувати знімки db . Ідея полягала в тому, щоб ініціювати знімок на кожен db (який повинен закінчитися за секунди), а потім повністю зробити резервне копіювання кожного послідовно протягом наступних хвилин / годин. Потім відновіть їх на іншому сервері та поверніть кожен на знімок. AFAIK такий сценарій неможливий, оскільки знімки неможливо створити резервну копію разом із базою даних. Їх можна повернути лише на місці, на сервері, де вони були створені. Крім того, вони вимагають Enterprise Edition, якого у мене немає для всіх клієнтів.

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

Мені потрібно створити резервну копію 10-20 dbs SQL Server, що використовуються одночасно одним корпоративним додатком, коли вони перебувають в Інтернеті, таким чином, щоб відновити їх до стану, який значною мірою синхронізується для всіх dbs

Те, що ви шукаєте, - це послідовне резервне копіювання у всіх ваших базах даних клієнтів, вам слід використовувати ПОВНІ резервні копії разом із Marked Transactions(наголос, що виділяється жирним шрифтом):

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

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

Мені потрібно рішення для версій SQL Server 2008 R2 та новіших версій. Розмір Db досягає 50 Гб на дБ, а час резервного копіювання всіх, ймовірно, перевищує 1-2 години.

Позначені транзакції працюватимуть для вашої ситуації. Єдине, що робити паралельні резервні копії - це STRIPEїх, але тоді ви в кінцевому підсумку переконайтеся, що ви не втратите свої смуги резервного копіювання. Щоб зробити їх швидшими, ви можете грати з BUFFERCOUNTі MAXTRANSFERSIZE.

Вам слід використовувати стиснення резервного копіювання , а також активувати миттєву ініціалізацію файлів .

Звертатися до

• Використання позначених транзакцій (модель повного відновлення)
• Як збільшити повну швидкість резервного копіювання бази даних SQL за допомогою компресійних і твердотілих дисків?

Якщо у вас запущені резервні копії, а також резервні копії журналу транзакцій (і якщо ви вважаєте, що ці дані є важливими), ви можете просто скопіювати резервні копії та резервні копії журналу транзакцій у тестову систему та виконати точне відновлення часу для відновлення баз даних у + - той самий час.

Залежно від того, чи всі бази даних перебувають на одній машині SQL Server або від того, наскільки добре синхронізовані годинники серверів, ви повинні мати можливість відповідати цілі «пару секунд десинхронізації».

Це може бути дещо рішенням про надання допомоги, але воно відповідатиме вимогам і буде досить простим і недорогим.

Якщо у вас немає повних резервних копій та резервних копій журналу транзакцій із важливих баз даних (які повністю відновлені), вам дійсно потрібно переглянути свою стратегію резервного копіювання. Знімки на рівні SAN насправді підтверджують можливість створення бази даних у повному режимі відновлення, оскільки ви не зможете відновити момент відновлення.

Прочитайте, будь ласка, що містер Денні на це має сказати

За вказаних вами обставин ви подивилися на резервні копії VSS через постачальника послуг VSS, який базується на сторонніх розробниках чи Microsoft? Ви можете виконати резервну копію COPY_ONLY, яка не розірве ланцюг відновлення виробництва, і вам слід створити резервну копію з усіх баз даних, до яких ви зможете відновити в іншому місці в межах ваших розумних запасів. Майте на увазі, що резервна копія VSS має деякі ті ж механізми та спади, що і знімки баз даних, оскільки дуже активна база даних може спричинити проблему з дисковим простором через розріджені файли. Ознайомтеся з ресурсами TechNet на службі SQL Writer тут і резервними копіями VSS SQL Server тут .

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

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

Для клієнтів, що використовують просту модель відновлення, мені знадобиться копія MDF та LDF, витягнута з тимчасового знімка диска, зробленого в T0 на рівні гіпервізора або SAN. Я можу використовувати їх для відновлення dbs у стані з T0.

Для клієнтів, які використовують повну модель відновлення, мені потрібно буде:

• Копії свого основного резервного копіювання останнього повного резервного копіювання завершено до T0 + мінімальний ланцюг подальших резервних копій журналу транзакцій, що охоплюють T0. Тоді я можу виконати точку відновлення часу до T0.

• Доступ для виконання власних допоміжних COPY_ONLYрезервних копій. Я розпочну їх все паралельно з T0, що повинно зайняти не більше декількох секунд, і це було моїм головним питанням № 1. Тоді, при відновленні, я виконаю момент відновлення до FirstLSN з кожної резервної копії. Краса цього в тому, що він не вимагає від мене взагалі взаємодії з основним процесом резервного копіювання, що було моєю іншою проблемою, вони можуть навіть усікати журнали, коли мої COPY_ONLYрезервні копії працюють, не впливаючи на їх узгодженість.

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