Внешнее резервное копирование Microsoft SQL Server 2008

Question

Я хотел бы сохранить свои резервные копии с сервера SQL 2008 на другом сервере. У нас есть 2 сервера:

• Сервер развертывания
• Файловый сервер

Проблема в том, что на сервере развертывания мало места. И мы храним резервные копии наших баз данных в течение 10 дней. Поэтому нам нужно хранить наши резервные копии на внешнем «файловом сервере». Проблема в том, что SQL этого не позволяет. Я попытался запустить службу SQL 2008 с учетной записью, которая имеет права администратора на обоих компьютерах (учетная запись домена), но это все равно не работает.

Любые мысли по этому поводу. В противном случае нам придется поместить внешний жесткий диск на сервер в стойку, и это немного глупо?

EDIT:

Я нашел способ заставить это работать. Вы должны поделиться папкой на сервере. Затем предоставьте серверу разработки (самому ПК) права на запись. Это сделает возможным внешнее резервное копирование на сервере SQL. Хотя я не знаю, безопасно ли это, я нахожу странным давать права компьютера на папку.

Answer 1

Вы можете использовать сторонние инструменты, такие как SqlBackupAndFTP

Answer 2

Есть несколько способов сделать это, уже описанные, но этот основан на моем проекте с открытым исходным кодом, SQL Server Compressed Backup . Это инструмент командной строки для резервного копирования баз данных SQL Server, и он может записывать в любое место, где работает пользователь NT, с которым он может писать. Просто запланируйте это в запланированных задачах, запущенных с пользователем с соответствующими разрешениями.

Пример резервного копирования на общий ресурс на другом сервере:

msbp.exe backup "db(database=model)" "gzip" "local(path=\\server\share\path\model.full.bak.gz)"

Доступны все параметры команды BACKUP, которые имеют смысл для резервного копирования файлов: журнал, разностный, copy_only, контрольная сумма и другие (например, параметры ленточного накопителя недоступны).

Answer 3

Вы можете создать небольшой и аккуратный пакет служб интеграции с SQL Server (SSIS), чтобы выполнить резервное копирование, а затем переместить данные в альтернативное хранилище файлов.

Интересно, что планы обслуживания в SQL Server фактически используют компоненты служб SSIS. Эти же компоненты доступны для использования в Business Intelligence Design Studio (BIDS).

Надеюсь, это понятно, но дайте мне знать, если вам понадобится дополнительная помощь.

Ура, Джон

Answer 4

вы можете использовать планировщик для перемещения резервных копий через определенное время после начала резервного копирования с использованием пакетного файла.

Если я правильно помню, есть способ взломать сервер sql для резервного копирования на удаленное хранилище, но я не думаю, что взломать - это путь.

Конечно, лучшая возможность может заключаться в использовании внешнего инструмента резервного копирования, который поддерживает использование агентов. Они контролируют, когда начинается резервное копирование, и следят за перемещением файлов.

Sascha

Answer 5

Некоторое стороннее программное обеспечение для резервного копирования позволяет устанавливать определенные разрешения пользователей для сетевых расположений. Поэтому не имеет значения, какие разрешения имеет учетная запись службы SQL Server. Я бы порекомендовал вам попробовать EMS SQL Backup, которая также поддерживает сжатие резервных копий «на лету» для экономии места на диске.

Answer 6

Мой опыт работы со старыми версиями MSSQL, поэтому в SQL2008 могут быть вещи, которые помогут вам лучше.

У нас очень мало свободного места на некоторых наших старых серверах. Это машины нашего провайдера, и время их восстановления с ленты не очень хорошее - 24 часа не редкость :( поэтому нам нужно вести приличную оперативную историю резервного копирования.

В воскресенье мы выполняем полное резервное копирование, разностное резервирование каждую ночь, а резервное копирование TLog каждые 10 минут.

Мы принудительно создаем резервные копии Tlog каждую минуту во время дефрагментации таблиц / индексов и обновления статистики - это потому, что они являются наиболее интенсивными TLog-задачами, которые мы выполняем, и ранее они отвечали за определение размера постоянного файла Tlog; с момента этого изменения мы смогли запустить размер стояния TLog примерно на 60% меньше, чем раньше.

Хотя стоит посмотреть размер резервных копий Diff - если окажется, что к моменту создания резервной копии в среду ваша резервная копия DIFF приближается к размеру полной резервной копии, вы можете также запускать полную резервную копию два раза в неделю и иметь меньшие резервные копии Diff. на следующий день или два.

При удалении файлов резервных копий Full или Diff (для восстановления дискового пространства) обязательно удалите ранее созданные резервные копии TLog. Но подумайте о вашем пути восстановления - хотите ли вы иметь возможность восстановить полное резервное копирование в прошлое воскресенье и все Tlogs с тех пор, или вы счастливы, что для моментального восстановления вы можете вернуться только к резервному копированию DIFF прошлой ночью? (то есть, чтобы вернуться дальше, вы можете восстановить только в резервную копию FULL / DIFF, а не в определенный момент времени). Если позднее вы сможете удалить все более ранние резервные копии Tlog, как только сделаете резервную копию DIFF.

(Очевидно, что независимо от того, что вам нужно сделать резервные копии на ленте и т. Д. И на вашем сервере копирования, вам просто не нужно зависеть от восстановления на ленте, чтобы выполнить восстановление, но вы теряете детализацию восстановления со временем)

Мы можем восстановить последнее заполнение (или последнее заполнение плюс DIFF в понедельник) во «временную базу данных», чтобы что-то проверить, а затем отбросить эту БД, но если нам действительно ДЕЙСТВИТЕЛЬНО пришлось восстановить значение «в прошлый понедельник, 15 минут». -past-10 AM "мы бы смирились с необходимостью получать резервные копии с ленты или с сервера копирования.

Все наши файлы резервных копий находятся в каталоге NTFS с установленным Compress. (Вы, вероятно, можете сделать сжатые резервные копии непосредственно из SQL2008, серверы, которые у нас не хватает дисков, работают под управлением SQL2000). Я читал, что это осуждается, но никогда не видел веских аргументов в пользу этого, и у нас никогда не было с этим проблем - дотронься до дерева!