Приєднати / від'єднати відносно резервного копіювання / відновлення

Мені потрібно перенести базу даних (в цілому) на інший сервер, щоб зробити дублікат бази даних для установки іншого тестового середовища.

У мене є два варіанти:

1. Зробити повну резервну копію на вихідному сервері / відновити на сервері призначення;
2. Від'єднати на вихідному сервері / приєднати на сервері призначення.

Які плюси і мінуси двох рішень відповідно до моїх вимог?

Я використовую SQL Server 2008 Enterprise.

Резервне копіювання / відновлення зазвичай повинно бути вашим методом вибору. Це буде швидше в більшості ситуацій.

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

Дивіться також це пов’язане питання, де згадується резервне копіювання / відновлення vs detach / attach:

SQL Server міграції відновлення резервного копіювання проти копіювання даних та файлів журналів

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

1. Відлучення бази даних перенесе її в автономний режим. Зробіть резервну копію, якщо вам потрібно залишатись в Інтернеті, коли ви копіюєте її на інший сервер.
2. Переміщення та відновлення файлу резервної копії (.bak) може бути простішим / простішим, ніж переміщення та приєднання декількох файлів mdf / ldf (як би ви відключили базу даних).
3. На папері вилучення / вкладення бази даних може бути технічно швидшим, але на практиці резервне копіювання / відновлення, швидше за все, буде швидшим і простішим. Коли ви від'єднуєте базу даних, спочатку ви повинні взяти оригінальну базу даних в автономному режимі (від'єднати всіх і все), а потім база даних буде недоступною, поки ви не повторно вкладете. Ви також повинні відслідковувати всі файли, тоді як із резервною копією всі файли згруповані.

Якщо ви вирішили створити резервну копію / відновити, під час резервного копіювання використовуйте опцію WITH COPY_ONLY, щоб переконатися, що ланцюг резервного копіювання будь-якого існуючого плану технічного обслуговування не порушений.

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

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

Особливо, якщо ви робите конверсію "виробництво для тестування", важливо, щоб виробнича база даних залишалася в Інтернеті.

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

Крім того, для мене (хоча це більше відчуття, ніж все інше), резервне копіювання / відновлення - це "повсякденна робота", тоді як вилучення / приєднання - це те, що ви робите у виняткових обставинах. Не запитуйте мене, звідки мені ця ідея ;-)

У мене завжди були проблеми з частиною "відновлення" резервного копіювання / відновлення. Я не можу навести конкретику, оскільки я врешті-решт відмовився від цього і з тих пір відкручую / копіюю / додаю.

Єдине, що стосується відокремлення - це те, що у вас є, щоб переконатися, що СУБД також не збирається також видаляти базу даних. Мав це статися, і це не дуже видовище.

Я рекомендую створити copy_onlyрезервну копію цього методу з оболонки DOS (щоб ви не переривали журнали транзакцій) :

Запустити з C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupкаталогу:

backup.bat SQLDBNAME

Де backup.batміститься (додається розрив рядка для читабельності) :

sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME 
    -Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"