При проведении презентаций по резервному копированию и восстановлению баз данных SQL Server обычно задаются два типа вопросов.
Первые задаются прямо во время выступления из зала, вторые – после, в приватной беседе.
Эти «частные» вопросы зачастую более интересны и я постараюсь дать ответы на самые сложные и интересные из них, вместо того, чтобы писать очередную статью о том, как следует делать резервные копии, или почему следует делать резервные копии, или даже зачем проверять их резервные копии (но вам действительно следует проверить свои резервные копии).
Могу ли я развернуть резервную копию на версии SQL Server, отличной от той, на которой была сделана резервная копия? Какие проблемы могут возникнуть?
Вы можете восстановить резервную копию на другой версии SQL Server, но только если версия SQL Server, на которой вы развертываете резервную копию, новее той, на которой вы ее сделали.Другими словами, вы можете развернуть резервное копирование с SQL Server 2000 на SQL Server 2005, с SQL Server 2005 на SQL Server 2008 R2 или с SQL Server 2008 на SQL Server 2012, но вы никогда не сможете сделать это в обратном направлении.
.
Каждая версия SQL Server вносит свои собственные изменения в базу данных и файлы, в которых она хранится.
Microsoft не будет возвращаться в прошлое и переписывать предыдущие версии SQL Server для поддержки этих изменений.
Если вам действительно нужно перейти на более старую версию SQL Server, вам нужно будет написать схему и сами данные в сценарии (например, здесь статья посвященная такому переходу ) Чтобы определить, на какой версии SQL Server была создана резервная копия, нужно посмотреть заголовок файла резервной копии:
В результате вы увидите версии Major, Minor и Build экземпляра SQL Server, на котором была сделана резервная копия (как показано на скриншоте ниже).RESTORE HEADERONLY FROM DISK = 'd:\bu\mm.bak';
Это позволит вам определить подходящую версию SQL Server для восстановления этой резервной копии.
При восстановлении базы данных на более новую версию SQL Server может оказаться, что в ней есть что-то несовместимое с этой версией SQL Server. Самый безопасный подход к переходу на новую версию SQL Server — запустить Microsoft Upgrade Advisor (бесплатную утилиту, доступную для каждой версии SQL Server) в базе данных, которую вы хотите перенести, убедиться, что она готова, а затем создать ее резервную копию и восстановить его на новом экземпляре (но только в таком порядке, а не пытаться сначала перенести бэкап, а потом запустить помощник).
После восстановления база данных будет находиться в режиме совместимости с той версией SQL Server, с которой был произведен переход. Это означает, что он будет иметь доступ только к тем функциям, которые поддерживались версией SQL Server, на которой была создана резервная копия.
Чтобы в полной мере воспользоваться преимуществами новой версии SQL Server, необходимо изменить уровень совместимости базы данных.
Это можно сделать с помощью графического интерфейса или с помощью скрипта: ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;
Разные числа обозначают разные версии SQL Server: 90 для SQL Server 2005, 100 для SQL Server 2008 и 2008 R2 и 110 для SQL Server 2012 ( Вы можете узнать больше о версиях SQL Server. Здесь — ок.
переводчик ).
Стоит добавить, что не все «переходы» возможны.
SQL Server позволит вам «прыгнуть вперед» только на две версии.
Например, вы не можете развернуть резервную копию, сделанную из SQL Server 2000, на SQL Server 2012. Сначала вам нужно будет развернуть ее на SQL Server 2008, установить соответствующий уровень совместимости, создать новую резервную копию, а затем развернуть ее на SQL Server 2012.
Могу ли я использовать операцию восстановления для создания копии базы данных? Что может пойти не так?
Да, ты можешь сделать это.Если вы разворачиваете резервную копию на другом сервере, то вам необходимо убедиться, что на новом сервере у вас те же логические диски, что и на «старом» сервере, либо вручную указать правильные пути к файлам базы данных с помощью команды С ПЕРЕМЕЩЕНИЕМ.
опция ВОССТАНОВИТЬ БАЗУ ДАННЫХ: RESTORE DATABASE NewDBName
FROM DISK = 'c:\bu\mm.bak'
WITH MOVE 'OldDB' TO 'c:\data\new_mm.mdf',
MOVE 'OldDB_Log' TO 'c:\data\new_mm_log.ldf';
Файлы базы данных имеют как логические имена, так и физические имена файлов.
Вам просто нужно ввести все логические имена файлов и определить новое физическое местоположение для каждого из них.
Основные проблемы, с которыми вы можете столкнуться, — это ошибки из-за недостаточного свободного места на дисках, на которые вы восстанавливаете базу данных, либо вы можете забыть указать новое имя базы данных и SQL Server попытается восстановить базу данных поверх существующей.
При восстановлении базы данных на новом сервере вы можете столкнуться с проблемой «Осиротевшие пользователи» ( пользователи, потерявшие связь со своей учетной записью, согласно переводу на msdn - ок.
переводчик ), если пользователь базы данных связан с учетной записью, которой нет на новом сервере.
Вам нужно будет исправить эту ошибку.
Могу ли я прикрепить файл MDF в качестве базы данных, если у меня нет файла журнала транзакций?
Это допустимо только в том случае, если журнал транзакций был утерян после корректного завершения работы базы данных.В любом случае это не очень хорошая идея.
При подключении базы данных для выполнения процесса восстановления базы данных необходим файл журнала транзакций, а также файл данных ( здесь под восстановлением базы данных понимается не операция ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ, а восстановление - процесс, происходящий при каждом запуске SQL Server, в ходе которого SQL Server "просматривает" журнал транзакций и приводит файлы данных в согласованное состояние - прим.
переводчик ).
Однако в некоторых случаях можно прикрепить файл данных без файла журнала транзакций, но этот вариант предназначен только для случаев, когда файл журнала транзакций был поврежден или утерян из-за проблем с оборудованием и отсутствия резервных копий.
Конечно, база данных не может существовать без журнала транзакций, и если вы прикрепите базу данных без файла журнала транзакций, SQL Server просто создаст ее заново.
Прикрепление файла данных без файла журнала транзакций разрушает цепочку журналов и, кроме того, может оказаться, что нарушается транзакционная или структурная целостность базы данных (в зависимости от состояния базы данных на момент «потери» журнала транзакций).
»).
Операция прикрепления такой базы данных может завершиться неудачей независимо от того, какие действия будут предприняты.
Копирование файлов данных и файлов журналов транзакций разрешено только после выполнения операции отсоединения или после корректного завершения процесса SQL Server — это гарантирует корректное завершение всех транзакций.
Копирование/перемещение файлов базы данных на другой сервер — это более быстрый способ перенести базу данных на другой сервер, чем создание/развертывание резервной копии, но он не так безопасен (если вы перемещаете файлы базы данных напрямую, не имея копий).
Также необходимо помнить, что прикрепить базу данных можно только на той же или более новой версии SQL Server.
Моя база данных находится в SAN. Я слышал, что резервных копий SAN достаточно.
Это верно? Это может быть правдой.
Главное, чтобы ваш SAN( Хранение данных, сеть/система хранения данных – ок.
переводчик ) поддерживал транзакции SQL Server. Если да, то он будет знать, что в базе данных есть транзакции и наличие этих транзакций может означать, что данные в файлах данных могут быть неполными, поскольку процесс записи измененных в этих транзакциях данных на жесткий диск может не быть завершено во время создания резервной копии.
Те резервные копии, которые делает сам SQL Server, естественно, учитывают эти моменты.
Например, EMC Data Domain представляет собой комбинацию программного обеспечения и SAN, которая обеспечивает поддержку транзакций, как и продукты других поставщиков, но вам все равно необходимо проверить документацию по SAN. Ищите такие фразы, как «согласованность транзакций», «осведомленность о транзакциях» или что-то подобное.
Если вы их не найдете, я бы посоветовал вам проверить восстановление базы данных, прежде чем вы решите, что резервных копий SAN достаточно для всех ваших требований к резервному копированию.
Однако даже после того, как вы убедились, что резервное копирование SAN выполняется правильно, это не означает, что вам больше не нужны «родные» резервные копии SQL Server. Например, если вам нужна возможность восстановить базу данных на определенный момент времени, вам все равно придется создавать резервные копии журнала транзакций с помощью SQL Server. Обычно при создании резервной копии сеть SAN с поддержкой SQL Server использует интерфейс SQL Server VDI и «замораживает» базу данных на время создания резервной копии.
Если вы запустите механизм создания такой резервной копии и посмотрите журнал ошибок SQL Server, то увидите там сообщения о том, что операции ввода-вывода были заморожены.
Если вы полагаетесь на резервные копии SAN, вам все равно необходимо выполнять проверку целостности базы данных либо в действующих базах данных, либо в копиях, восстановленных из резервной копии SAN. В противном случае вы можете долгое время создавать резервные копии поврежденной базы данных и даже не знать об этом.
Почему я не могу использовать копии файлов данных, созданные Windows, в качестве резервных копий? Мне не нужна возможность восстановления в произвольный момент времени.
SQL Server — это не обычное настольное приложение.
Он управляет своими файлами таким образом, чтобы гарантировать, что все свойства ACID (атомарные, согласованные, изолированные, прочные) немного подробнее — ок.
переводчик ).
Короче говоря, чтобы обеспечить успешное завершение транзакций, SQL Server старается никому не предоставлять доступ к своим файлам и сам модифицирует их по мере необходимости.
Если вы просто скопируете файл данных, игнорируя блокировки и транзакции, которые могут выполняться в данный момент, это означает, что при попытке прикрепить файл позже он окажется в несогласованном состоянии, что приведет к ошибкам.
Только если база данных вообще не изменится, вы сможете скопировать файл и прикрепить его позже.
Если существует хотя бы минимальная вероятность того, что при копировании файла была открыта хотя бы одна транзакция, скорее всего, вы получите неудачную резервную копию.
Единственный безопасный способ скопировать файлы данных и журналы транзакций для использования в качестве резервных копий — отключить базу данных перед копированием.
Гораздо безопаснее и проще использовать встроенный механизм SQL Server. для создания резервных копий.
Такая резервная копия будет полной копией вашей базы данных, и все свойства ACID будут выполнены.
У меня очень маленькая база данных.
Почему я не могу просто «сбросить» каждую таблицу на диск для создания резервной копии? Можно использовать что-то вроде SQLCMD и сбрасывать таблицы в простой текстовый файл, но тогда вместо одной команды по восстановлению базы данных придется запускать целую серию команд. Сначала вам нужно будет создать пустую базу данных.
Затем вам нужно будет создать и загрузить каждую таблицу из файла.
Если какая-либо таблица содержит столбец IDENTITY, вам потребуется выполнить SET IDENTITY_INSERT для каждой из этих таблиц.
Кроме того, вам придется тщательно определить порядок загрузки данных в таблицы, чтобы обеспечить согласованность.
Плюс учтите, что все ваши таблицы загружаются на диск в разное время, поэтому если в процессе загрузки данные каким-то образом изменились, то после восстановления вы не получите базу данных в целости и сохранности и вам придется вручную искать ошибки и исправлять их.
их.
Конечно, вы имеете на это право.
С другой стороны, вы можете просто запустить команду BACKUP DATABASE, а затем при необходимости восстановить эту резервную копию.
Зачем платить деньги за утилиты, создающие резервные копии, если SQL Server может сделать это сам?
Есть три основные причины использовать стороннее программное обеспечение для резервного копирования: руководство, автоматизация и функциональность.Если вы начинающий администратор баз данных или вообще не администратор баз данных, но вынуждены обслуживать СУБД в качестве дополнения к основной работе, вы можете не знать, как, где и зачем нужно настраивать резервное копирование в SQL Server. Хорошая утилита (например, SQL Backup Pro) может предоставить вам именно те рекомендации, которые вам необходимы для обеспечения безопасности ваших баз данных посредством резервного копирования.
Резервные копии, созданные самим SQL Server, работают прекрасно, но нужно проделать большую работу по их настройке и еще больше по их автоматизации.
Хорошая сторонняя утилита сделает процесс автоматизации очень простым.
Более того, с его помощью вы можете автоматизировать и другие процессы, связанные с резервным копированием, такие как зеркалирование/доставка логов и проверка целостности резервной копии.
Наконец, хотя резервные копии SQL Server и делают то, что вам нужно, они могут делать это не лучшим образом.
Например, некоторые утилиты более эффективно сжимают резервные копии, тем самым экономя больше дискового пространства и сокращая время резервного копирования.
Также добавляются функциональные возможности, такие как шифрование файла резервной копии (нечто подобное возможно с помощью встроенных средств SQL Server, только если сама база данных зашифрована).
Если резервная копия находится в сетевой папке, может ли кто-нибудь ее прочитать?
Если вы не зашифровали сам файл резервной копии, да, это самый обычный файл.Если кто-то получит доступ к этому общему ресурсу, он сможет прочитать его в любом текстовом редакторе или просто скопировать и начать восстановление с него на другом экземпляре SQL Server. Более того, вы можете получить схему базы данных или данные из резервной копии, даже не восстанавливая их.
Если у вас есть утилита SQL Data Compare, то она, запущенная с ключом /Export, сможет извлечь все данные из резервной копии в формате CSV, сравнив эту резервную копию с пустой базой данных и не запрашивая никакого пароля.
Кроме того, тот же SQL Data Compare может создать для вас скрипт, создающий схему базы данных.
Чтобы предотвратить несанкционированный доступ к вашей резервной копии, вам придется сделать несколько вещей.
Во-первых, убедитесь, что общий ресурс, на котором хранятся резервные копии, доступен ограниченному числу людей.
Во-вторых, вам следует хранить только те резервные копии, которые вам действительно нужны.
Наконец, если вы используете стороннюю утилиту резервного копирования (например, SQL Backup Pro), вы можете зашифровать резервную копию, так что даже если кто-то получит прямой доступ к файлу, он не сможет ничего из него прочитать.
Без сторонних утилит этого можно добиться с помощью прозрачного шифрования данных (TDE).
Чтобы обеспечить наилучший уровень безопасности, вам необходимо выполнить все вышеперечисленные шаги.
Может ли кто-нибудь изменить содержимое резервной копии?
Нет возможности изменить содержимое файла резервной копии.Поскольку резервная копия представляет собой постраничную копию базы данных (в том виде, в котором она существовала на момент создания резервной копии), то восстановленная копия этой базы данных будет находиться точно в том же состоянии, в котором находился оригинал на момент создания резервной копии.
время создания резервной копии.
Когда SQL Server читает каждую страницу во время восстановления базы данных, он вычисляет ее контрольную сумму в зависимости от ее содержимого и сравнивает ее со значением, которое было прочитано из исходной страницы во время создания резервной копии (при условии, что при создании резервной копии вы использовали параметр С КОНТРОЛЬНОЙ СУММОЙ).
резервное копирование).
Если кто-то внес изменения в файл резервной копии, эти значения не совпадут, и SQL Server пометит страницу как поврежденную.
Есть ли какой-нибудь флаг, который, установив его при создании резервной копии, я могу быть уверен, что всегда смогу из нее восстановиться?
Если под этим флагом вы подразумеваете, что ваш процесс резервного копирования включает в себя выполнение операции RESTORE VERIFYONLY после создания резервной копии, то нет, вы не можете быть уверены, что сможете восстановить базу данных из этой резервной копии.RESTORE VERIFYONLY может выполнять набор из двух проверок.
Сначала он проверяет заголовок резервной копии, чтобы убедиться в отсутствии в нем ошибок.
Если заголовок поврежден, то восстановить базу данных из этой резервной копии не получится.
RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'
Вторая проверка возможна только в том случае, если вы запускали процедуру резервного копирования с опцией С КОНТРОЛЬНОЙ СУММОЙ.
Это означает, что в процессе резервного копирования SQL Server пересчитывает и проверяет контрольные суммы для всех прочитанных страниц.
Если ему встретится страница, для которой эти суммы не складываются, операция резервного копирования завершится неудачно.
Если проверка прошла успешно, BACKUP With CHECKSUM рассчитает и запишет контрольную сумму созданной копии.
Соответственно, RESTORE VERIFYONLY можно использовать для пересчета контрольной суммы и проверки того, что резервная копия не была повреждена во время хранения.
RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'
WITH CHECKSUM
Проблемы могут возникнуть в двух местах.
Во-первых, проверка заголовка при выполнении VERIFYONLY не проверяет все, что может повлиять на процесс восстановления.
Это означает, что RESTORE VERIFYONLY может завершиться без ошибок, но базу данных все равно невозможно восстановить из «проверенной» копии.
Во-вторых, CHECKSUM не может обнаружить повреждение, произошедшее в памяти.
Если страница данных была обновлена, пока она находилась в памяти, а затем была повреждена до того, как она была записана на диск (и, следовательно, в резервную копию), то вычисление контрольной суммы не покажет никакой ошибки, а просто подтвердит, что в резервную копию были записаны те же данные.
.
страница, которая содержалась в базе данных на момент создания резервной копии.
Те.
если страница уже была повреждена при создании резервной копии, ошибку невозможно обнаружить по контрольной сумме, и восстановление из этой резервной копии может завершиться неудачно.
Единственный способ точно узнать, что восстановление из резервной копии возможно и что полученная база данных не повреждена, — это восстановить ее и, желательно, запустить проверку целостности базы данных на восстановленной копии.
Содержит ли резервная копия что-либо, кроме данных? Кто-нибудь может прочитать пароли от него?
Резервная копия содержит больше, чем просто данные.Он содержит всю структуру базы данных.
Он включает в себя все данные, процедуры, представления, функции и весь остальной код. Также он содержит все настройки базы данных.
Наконец, он содержит всю информацию о пользователях базы данных.
В обычной базе данных каждый пользователь базы данных связан с учетной записью SQL Server. Пароли таких пользователей хранятся вместе с учетной записью, поэтому в резервной копии эти пароли не будут. Однако в автономных базах данных ( содержащиеся базы данных — ок.
переводчик ) существует понятие ПОЛЬЗОВАТЕЛЬ С ПАРОЛЕМ, поскольку сама идея автономных баз данных предполагает минимальную связь между такой базой данных и сервером.
В этом случае пароль окажется в резервной копии, что может привести к попыткам получить его оттуда.
Пароли не хранятся в открытом виде, они хэшируются, как и пароли учетных записей (которые хранятся в базе данных главной системы и, конечно же, попадают в ее резервную копию).
Microsoft предлагает несколько лучшие практики о безопасности автономных баз данных.
Зачем вам индексы, статистика и прочее, что легко воссоздать в резервной копии? Это просто пустая трата времени?
И, по моему мнению, это пустая трата времени, пытаясь разделить вещи таким образом и создать резервную копию только одной части.Во-первых, как это сделать? Например, как сделать резервную копию данных, не делая резервную копию кластерных индексов? Это невозможно, поскольку конечный уровень кластеризованного индекса — это страницы данных.
То есть можно сказать, что кластерные индексы — это сами таблицы, поэтому кластерные индексы необходимо включать в резервную копию.
Конечно, можно выделить некластеризованные индексы в отдельную файловую группу и не делать ее резервную копию, но тогда, после восстановления той резервной копии, которая у нас есть, нам все равно придется возвращать к жизни эту файловую группу и пересобирать все индексы.
Так чего же мы достигнем? Также будут проблемы со статистикой.
SQL Server создает резервную копию статистики вместе с базой данных (причем она занимает очень мало места, поскольку гистограмма, называемая статистикой, строится всего из 200 строк) и восстанавливает ее вместе с базой данных.
Однако если после восстановления мы начнем пересоздавать индексы, поскольку мы не сделали их резервные копии, нам придется воссоздавать и статистику.
Это также потребует дополнительного времени, а база данных при этом останется недоступной.
В конечном итоге я бы поспорил с словосочетанием «легко воссоздается», потому что в экстренной ситуации весь этот процесс может сильно запутаться, что неизбежно приведет к тому, что люди, работающие с этой базой данных, не смогут получить к ней доступ гораздо больше времени, чем в случай простого восстановления из резервной копии.
Вся идея создания резервной копии состоит в том, чтобы иметь возможность максимально быстро и эффективно восстановить базу данных.
Чем сложнее процесс восстановления, тем менее эффективным является резервное копирование.
Да, для хранения индексов, пользователей, хранимых процедур и всего остального требуется дополнительное пространство, но повышенная скорость восстановления за счет хранения всего в одном месте стоит дополнительного места.
МОЙ БОГ! Я только что удалил таблицу! Я знаю, что это есть в журнале транзакций.
Как я могу его вернуть? После фиксации транзакции SQL Server не сможет ее отменить.
Операции DELETE и TRUNCATE удаляют данные совершенно разными способами.
Операция DELETE удаляет данные с помощью транзакций, удаляющих каждую строку.
Операция TRUNCATE просто помечает страницы данных, содержащие данные, подлежащие удалению, как неиспользуемые.
Но ни одну из этих операций нельзя выполнить вручную, просмотрев журнал транзакций.
Вместо этого вам необходимо выполнить процесс, называемый восстановлением на определенный момент времени.
Вам следует немедленно сделать резервную копию журнала транзакций вашей базы данных, чтобы сохранить все внесенные изменения до того, как вы случайно удалите необходимые данные из таблицы.
Затем вам необходимо выполнить шаги, описанные в главе 6. эта книга восстановить до момента времени ( в MSDN тоже все – ок.
переводчик ).
Другой вариант — использовать сторонние утилиты, такие как SQL Backup Pro, которые могут восстанавливать отдельные объекты базы данных в режиме онлайн из существующих резервных копий.
Что, если я просто хочу создать скрипт для создания базы данных с использованием резервной копии, не восстанавливая саму резервную копию.
? Стандартных инструментов для создания такого скрипта в SQL Server нет. Однако такие утилиты, как SQL Compare, могут его сгенерировать.
Его легко создать с помощью графического интерфейса, но это также возможно с помощью PowerShell: & 'C:\Program Files (x86)\Red Gate\SQL Compare 8\SQLCompare.exe' /Backup1:C:\MyBackups\MyBackupFile.bak /MakeScripts:"C:\MyScripts\MyBackupScript"
Также вы можете обратить внимание на SQL Virtual Restore. Эта утилита позволяет вам подключить резервную копию к вашему SQL Server, как если бы вы запускали процесс восстановления из этой резервной копии, но не требует использования всего пространства, которое может потребоваться во время восстановления.
Смонтированная таким образом резервная копия выглядит как обычная база данных и ее можно заскриптовать любым удобным для вас способом.
От переводчика: Грант довольно активно рекламировал утилиты своей компании на протяжении всей статьи, я постарался это немного сгладить.
Названия остаются, и если кому-то нужны ссылки, их достаточно легко найти в Интернете (или спросить в личном сообщении).
Как обычно, приветствуются любые предложения и исправления по поводу перевода и стиля.
Теги: #sql-сервер #резервное копирование #восстановление #восстановление #восстановление на момент времени #Microsoft SQL Server
-
Я Удивлен, Что Ваш Продукт Все Еще Работает.
19 Oct, 24 -
Есть Ли Жизнь После 30: История Ciscosystems
19 Oct, 24 -
Обновление Yota Access На Модеме
19 Oct, 24 -
Потрясающая Экскурсия От Наса По Мкс В 4К
19 Oct, 24 -
Подготовка К Ccna 200-301
19 Oct, 24
