Comments 27
При выполнении бэкапа на шару, у учётной записи, под которой запущен SQL Server, должны быть права для записи туда.
можно вот так сначала сделать
-- enable xp_cmdshell
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
GO
EXEC xp_cmdshell 'net use l: \\10.1.1.1\backups /user:domain\username PASSWORD'
--EXEC xp_cmdshell 'net use l: \\storage\backup'
GO
--EXEC xp_cmdshell 'net use l: /delete'
-- disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0
RECONFIGURE
GOи соответственно все бэкапы делать на диск L
Есть такая поговорка: Code is a liability not an asset. Вы написали простыню business-cricial кода, в котором пустое множество тестов. Если вы такое оставите после себя работодателю, ваш вклад в компанию будет отрицательным.
Откуда вы знаете, что эта штука работает?
Человек чем-то работающим поделился, а вы ещё и недовольны :-). Ну юзайте платное ПО, может там меньше ошибок или лучше тесты, но вы это никогда не узнаете, т. к. оно чёрный ящик. А тут простой скрипт, всё на виду. Хочется сделать ещё более безопасно — допишите и поделитесь результатом. Хаять чужие решения больно все горазды.
При узком канале я бы пожалуй rar-ом воспользовался, а не встроенной компрессией. Ну и скрипт в шелле, запускающий бекапы через sqlcmd. Наверное :)
Detach — копирование — Attach рассматривался, но не подошёл, поскольку канал был довольно узким и перенос БД в несжатом виде занял бы довольно большой промежуток времени.
Кстати, действительно, что мешало сделать промежуточное сжатие выключенной БД перед копированием.
Тут месяц назад как раз была тема выбора оптимальной стратегии сжатия.
habr.com/en/company/homecredit/blog/484414
Этот вариант удобен тем, что время простоя минимально — пока бэкап льётся по узкому каналу, бд доступна на старом экземпляре. При желании, можно дополнительно заморочиться на бэкапы журналов транзакций и сделать простой ещё меньше.
>А тут всё стандартными средствами
Проверил на первой попавшейся базе, sql жмет чуть лучше, и значительно быстрее, чем даже 7zip. И это с файлами базы, которые уже обрезаны.
Другое дело, когда есть счастливчики с 2005 или Express-версиями.
>бд доступна на старом экземпляре.
Но ведь, тогда бэкап перестанет быть актуальным, если пользователи что-то запишут в базу, и эти данные пропадут. Опять-таки в вашем случае, может это и не было критично.
При том, что сжатый штатными средствами бекап — мгновенно доступен для восстановления, и не требует дополнительного места для декомпрессии.
Великий Гуру, молю, укажите направление! Очень хочу просветления
ms sql server backup в гугле набрать, если не забанен.
нельзя к sql server относится как к обычной СУРБД, это скорее комплекс, в отличие например от разных посгесов и марий, поверьте, там все идет в коробке, а если Вы об этом не знаете, то это не вина продукта, а только ваше незнание, прошу не обижаться. Если бы Вы хоть теорию знали, вы не пошли бы таким путем, а мне лень писать в 2 раза больше, чем Вы накатали. Все поймете с возрастом и опытом.
Могу посоветовать интересную (решаемую) задачу. Разверните 3 например экземпляра на одном ипе и одном порту. Вы очень много нового сами для себя узнаете.
работать всё должно начиная с SQL Server 2008 (или 2008 R2, не помню где появилось сжатие бэкапов)В 2008 сжатие работало только в Enterprise версии, начиная с 2008 R2 оно работает и в версии Standard
При выполнении бэкапа на шару, у учётной записи, под которой запущен SQL Server, должны быть права для записи туда.Верно, если только учетная запись доменная. Если она локальная, то на шару нужно добавлять доступ для учетки сервера на которой запущен SQL сервер.
За статью, спасибо :)
Когда мне довелось решать такую задачу, мне помог Data Migration Assistant. Утилита скачивается с сайта Microsoft. Все тоже самое: сделать бэкапы и залить на шару, восстановить из бэкапа на целевом сервере. + Переносит логины (с паролями). И при этом ни строчки кода не писал для этого.
Перенос всех баз данных MS SQL Server на другую машину