Принимая резервные копии из баз данных, является ли "хорошей практикой" использование логического устройства резервного копирования для размещения резервных копий? В чем преимущество использования устройств резервного копирования?
Представьте, что у вас может быть много заданий резервного копирования. Полные резервные копии, дифференциальные резервные копии, резервные копии журналов транзакций ... Теперь представьте, что вам нужно переместить все резервные копии с локального диска в SAN. Если вы используете устройства резервного копирования, вам просто нужно заново создать устройства с путями к новому диску. Но если ваши сценарии резервного копирования написаны с использованием полных путей, вам нужно переписать каждое задание, каждый шаг задания, чтобы изменить эти пути.
Но может быть сценарий, когда вам не нужно использовать устройства резервного копирования, например, когда вы используете какой-то пользовательский сценарий, когда вы динамически изменяете путь резервного копирования или имя файла (например, добавляя дату / время к папке или имени файла).
Я предпочитаю один файл на резервную копию
Я не хочу:
Если у вас есть база данных размера TB, разделы, файловые группы и вы хотите сделать частичное резервное копирование / восстановление, то эти проблемы умножаются. В ситуации с DR я хочу, чтобы все было просто и понятно.
Большинство (больших и маленьких) магазинов, в которых я был, делают это: проще иметь дело с файлами с самоописанием.
Концепция «устройства» восходит к Sybase, SQL Server 6.5 и более ранним версиям. Здесь у вас тоже были дисковые устройства. Отдельные MDF и LDF были представлены в SQL Server 7.
источник
Логическое устройство резервного копирования - это просто абстракция от физического устройства.
Это упрощает переключение между физическими устройствами, поскольку вы можете изменить определение логического устройства, а не редактировать сценарии резервного копирования или пакеты обслуживания.
источник
Я использовал устройство логического резервного копирования для системы отчетов, где мы хотели выполнить несколько восстановлений и не хотели записывать полный путь. Мы могли бы легко изменить определение устройства дампа без необходимости изменять наши сценарии.
Я полагаю, что та же самая концепция применима к использованию устройства логического дампа для резервного копирования на ленту, хотя мы никогда не делали дамп прямо на ленту.
Это единственные преимущества, которые я знаю прямо сейчас.
источник
Несмотря на то, что они используются, я предпочитаю придерживаться одной полной, дифференциальной или резервной копии журнала транзакций на файл, так как это упрощает запуск сценариев очистки для удаления старых резервных копий и предотвращения заполнения резервных дисков.
источник
Насколько я понимаю, выгода от использования устройства резервного копирования заключается в упрощении сценариев, что упрощает, если вам нужно перемещать диски или устройства, и, на мой взгляд, самое полезное; возможность иметь единый сценарий резервного копирования на нескольких серверах, где местоположение резервного копирования может быть определено для каждого сервера отдельно, но устройство резервного копирования может оставаться одинаковым на всех серверах. Например "Primary_Backup_Location".
источник
Помимо того, что уже было написано выше, единственная другая причина, по которой я мог видеть использование устройств резервного копирования, это ограниченность пространства. Если у вас есть 100 ГБ БД и 2 диска с 60 ГБ свободного места на каждом, вы можете создать устройство резервного копирования на каждом диске и выполнить резервное копирование на обоих. Предостережение в том, что для восстановления вам понадобятся оба устройства.
-Крис
- Конечно, вы можете записать в несколько файлов резервных копий, а не устройства тоже.
источник