Бэкап sql базы: Резервное копирование и восстановление базы данных в MS SQL Server

Содержание

Как сделать бэкап локальной базы данных MSSQL

Для разворачивания сайта Вы можете сделать бэкап локальной базы данных MSSQL,
а затем восстановить базу данных на сервере, воспользовавшись инструкцией Как восстановить бэкап базы данных MSSQL

1. Войдите в Microsoft SQL Management Studio, в списке баз данных выберите соответсвующую базу,
для которой будет сделан бэкап. Нажмите правой кнопкой, в разделе «Tasks», выберите «Back Up…»:

2. Откроется окно для настройки параметров бэкапирования. Убедитесь, что выбрана соответствующая база данных.
Нажмите кнопку «Add…» для добавления пути к файлу, в котором будет храниться бэкап:

3. Откроется окно выбора пути для сохранения файла бэкапа. Нажмите кнопку «…»:

4. Выберите путь и введите имя файла бэкапа, нажмите «ОК». Используйте расширение «.bak» для файла бэкапа:

5. Нажмите «ОК» еще раз:

6. В окне настроек параметров бэкапа будет показан путь для сохранения файла бэкапа. Нажмите «ОК» для запуска процесса бэкапирования:

7. Если бэкапирование выполнилось без ошибок, Вы увидите соответствующее сообщение:

8. По указанному Вами на шаге 4 пути будет сохранен файл бэкапа, который Вы сможете использовать далее для восстановления базы данных на сервере:

Читайте далее: Как восстановить бэкап базы данных MSSQL

Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server / Хабр

В ходе проведения презентаций о бэкапах и восстановлении баз данных 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 был создан бэкап, нужно посмотреть заголовок файла бэкапа:

RESTORE HEADERONLY FROM DISK = 'd:\bu\mm.bak';

В результате вы увидите Major, Minor и Build-версии того экземпляра SQL Server, на котором был сделан бэкап (как показано на скриншоте снизу). Это позволит вам определить подходящую версию SQL Server для восстановления этого бэкапа.

При восстановлении БД на более новую версию SQL Server, может оказаться, что в ней присутствует что-то несовместимое с этой версией SQL Server. Наиболее безопасным подходом к переходу на новую версию SQL Server будет запуск Microsoft Upgrade Advisor (бесплатная утилита доступная для каждой версии SQL Server) на базе, которую требуется переносить, убедиться, что она готова, а затем сделать бэкап и восстановить её на новом экземпляре (но только в этом порядке, а не сначала попытаться перенести бэкап, а затем запустить помощника).

После восстановления, БД будет находиться в режиме совместимости с той версией SQL Server’а, с которой осуществлялся переход. Это означает, что ей будет доступен только тот функционал, который поддерживался версией SQL Server, на которой создавался бэкап. Для того, чтобы получить все преимущества новой версии SQL Server, нужно изменить уровень совместимости базы данных. Это можно сделать с помощью GUI, а можно скриптом:

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.

Могу ли я использовать операцию восстановления для создания копии базы даных? Что может пойти не так?

Да, вы можете это сделать. Если вы разворачиваете бэкап на другом сервере, то нужно убедиться в том, что на новом сервере у вас присутствуют те же самые логические диски, что и на «старом» сервере, либо вручную прописать правильные пути для файлов базы данных, используя опцию WITH MOVE команды RESTORE DATABASE:

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 будет пытаться восстановить базу данных поверх существующей БД.

Когда вы восстанавливаете БД на новом сервере, вы можете столкнуться с проблемой «Orphaned Users» (пользователей, утративших связь с учётной записью, согласно переводу на msdn – прим. переводчика), если пользователь базы данных связан с учётной записью, не представленной на новом сервере. Вам нужно будет исправить эту ошибку.

Можно ли присоединять как базу данных файл MDF, если у меня нет файла журнала транзакций?

Единственный вариант, когда это допустимо – если журнал транзакций был утерян уже после того как работа базы данных была корректно завершена. В любом случае – это не очень хорошая идея. При присоединении БД, файл журнала транзакций, так же как и файл данных, нужен для проведения процесса восстановления БД (здесь под восстановлением БД понимается не операция RESTORE DATABASE, а recovery – процесс, происходящий при каждом запуске SQL Server, при котором SQL Server «проходит» по журналу транзакций и приводит файлы данных в согласованное состояние – прим. переводчика). Тем не менее, в некоторых случаях возможно присоединение файла данных без файла журнала транзакций, но эта возможность предназначена только для тех случаев, когда файл журнала транзакций был повреждён или потерян в результате проблем с оборудованием и при отсутствии резервных копий. Конечно, база данных не может существовать без журнала транзакций, и при присоединении БД без файла журнала транзакций, SQL Server просто пересоздаст его.

Присоединение файла данных без файла журнала транзакций разрушает цепочку журналов и, в добавок, может оказаться, что в БД нарушена транзакционная или структурная целостность (в зависимости от состояния БД на момент «потери» журнала транзакций). Операция присоединения такой БД может завершаться ошибкой вне зависимости от того, какие бы действия не предпринимались.

Копирование файлов данных и файлов журнала транзакций допустимо только после выполнения операции отсоединения (detach), либо после того как процесс SQL Server был корректно завершён – это обеспечит корректное завершение всех транзакций. Копирование/перемещение файлов баз данных на другой сервер является более быстрым способом переноса БД на другой сервер, чем создание/разворачивание резервной копии, но не так безопасно (в том случае, если вы перемещаете непосредственно файлы БД, не имея копий). Так же, нужно помнить о том, что вы можете выполнить присоединение БД только на такой же или более новой версии SQL Server.

Моя БД лежит на SAN. Я слышал, что бэкапов SAN достаточно. Это правда?

Это может быть правдой. Главное чтобы ваша SAN (СХД, Сеть/Система Хранения Данных – прим. переводчика) поддерживала транзакции SQL Server. Если это так, тогда она будет знать о том, что в БД существуют транзакции и наличие этих транзакций может означать, что данные в файлах данных, могут быть не полными, поскольку процесс записи данных, изменённых в этих транзакциях, на жёсткий диск, может быть не завершён на момент создания резервной копии. Те бэкапы, которые делает сам SQL Server, естественно, учитывают эти моменты.

EMC Data Domain, например – это комбинация ПО и SAN, обеспечивающая поддержку транзакций, как и продукция других вендоров, но вам всё равно нужно проверить документацию вашего SAN. Обратите внимание на наличие фраз вроде «transaction consistency», или «transaction aware», или чего-то подобного. Если вы их не нашли, то я бы посоветовал вам проверить восстановление БД прежде чем вы решите, что бэкапов SAN вам достаточно для выполнения всех ваших требований к резервным копиям. Впрочем, даже после того, как вы убедились, что бэкапы SAN выполняются корректно, это вовсе не означает, что «родные» бэкапы SQL Server вам больше не нужны. Если вам нужна возможность восстановления вашей БД на момент времени, например, вам всё равно придётся делать бэкапы журнала транзакций средствами SQL Server.

Обычно, при создании бэкапа, SAN с поддержкой SQL Server, использует VDI-интерфейс SQL Server и «замораживает» БД на время создания резервной копии. Если вы запустите механизм создания такого бэкапа и посмотрите в журнал ошибок SQL Server, там вы увидите сообщения о том, что операции IO были заморожены.

Если вы полагаетесь на резервные копии создаваемые SAN, вам всё равно нужно проводить проверки целостности БД либо на «живых» БД, либо на копиях, восстановленных с бэкапа SAN. В противном случае, вы можете долгое время создавать бэкапы повреждённой БД и даже не знать об этом.

Почему я не могу использовать в качестве бэкапов копии файлов данных, созданных Windows? Мне не нужна возможность восстановления на произвольный момент времени.

SQL Server не является обычным десктопным приложением. Он управляет своими файлами таким образом, чтобы обеспечить выполнение всех свойств ACID (Atomic, Consistency, Isolated, Durable – чуть более подробно — прим. переводчика). Вкратце, чтобы обеспечить успешное завершение транзакций, SQL Server старается никому не давать доступ к своим файлам и сам модифицирует их так, как ему нужно.

Если вы просто скопируете файл данных, игнорируя блокировки и транзакции, которые могут выполняться в данный момент, это означает, что когда вы попробуете присоединить этот файл позже, он будет в несогласованном состоянии, что приведёт к ошибкам.

Только в том случае, когда база данных совершенно не изменяется, вы сможете скопировать файл и присоединить его позже. Если же существует хотя бы минимальная вероятность того, что в момент копирования файла была открыта хотя бы одна транзакция, скорее всего, вы получите неудачную резервную копию. Единственный безопасный способ копирования файлов данных и журналов транзакций для использования их в качестве бэкапов – это перевод БД в режим offline перед копированием.

Намного безопаснее и проще использовать встроенный механизм 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), вы можете зашифровать бэкап, так что если кто-то и получит доступ непосредственно к файлу, то прочитать оттуда ничего не сможет.

Без сторонних утилит, вы сможете этого добиться, используя Transparent Data Encryption (TDE).

Для обеспечения наилучшего уровня безопасности, вам нужно выполнять все вышеперечисленные действия.

А кто-нибудь может изменить содержимое резервной копии?

Возможности изменять содержимое файла резервной копии не предусмотрено. Поскольку бэкап это постраничная копия базы данных (в том виде в котором она существовала на момент создания бэкапа), восстановленная копия этой БД будет находиться в абсолютно том же состоянии, в котором оригинал был на момент создания бэкапа.
Когда SQL Server считывает каждую страницу, в ходе восстановления БД, он высчитывает её контрольную сумму, зависящую от её содержания, и сравнивает с тем значением, которое было прочитано с оригинальной страницы в момент создания бэкапа (подразумевается, что вы использовали параметр WITH CHECKSUM при создании резервной копии). Если кто-либо производил изменения в файле резервной копии, эти значения не совпадут и SQL Server отметит такую страницу как повреждённую.

Существует ли какой-либо флаг, установив который при создании бэкапа, я могу быть уверен, что всегда смогу из него восстановиться?

Если под таким флагом вы подразумеваете, что ваш процесс создания резервной копии включает в себя выполнение операции RESTORE VERIFYONLY после создания бэкапа, то нет, вы не можете быть уверены в том, что сможете восстановить БД из этого бэкапа. RESTORE VERIFYONLY может выполнять набор из двух проверок.

Во-первых, она проверяет заголовок бэкапа, чтобы убедиться, что в нём нет ошибок. Если заголовок повреждён, то вы не сможете восстановить БД из этого бэкапа.

RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'

Вторая проверка возможно только в том случае, если вы запускали процедуру создания резервной копии с параметром WITH CHECKSUM. Это означает, что в ходе создания резервной копии, SQL Server пересчитывает и сверяет контрольные суммы для всех прочитанных страниц. Если он наткнётся на страницу, для которой эти суммы не сойдутся, операция создания резервной копии завершится с ошибкой. Если проверка завершается успешно, BACKUP WITH CHECKSUM вычислит и запишет контрольную сумму созданной копии.

Соответственно, RESTORE VERIFYONLY может использоваться для пересчёта контрольной суммы и проверки того, что за время хранения резервная копия не была повреждена

RESTORE VERIFYONLY
FROM DISK= '<Backup_location>'
WITH CHECKSUM

Проблемы могут возникнуть в двух местах. Во первых, проверка заголовка в ходе выполнения VERIFYONLY не проверяет всё что может повлиять на процесс восстановления. Это означает, что RESTORE VERIFYONLY может завершиться без ошибок, но БД всё равно не сможет быть восстановлена из «проверенной» копии.

Во-вторых, CHECKSUM не может обнаружить повреждения, произошедшие в памяти. Если страница данных была обновлена, находясь в памяти и затем произошло её повреждение прежде чем она была записана на диск (и, соответственно, в бэкап), тогда вычисление контрольной суммы не покажет никакой ошибки, а просто подтвердит, что в бэкап была записана та же страница, что и содержалась в БД в момент создания бэкапа. Т.е. если страница уже была повреждена в момент создания бэкапа, ошибка не может быть найдена с помощью контрольной суммы и восстановление из этого бэкапа может завершиться ошибкой.

Единственный способ узнать наверняка, что из бэкапа можно восстановиться и полученная БД не повреждена – это восстановить его и, желательно, запустить проверку целостности БД на восстановленной копии.

Не содержит ли бэкап что-нибудь кроме данных? Может ли кто-нибудь прочесть пароли из него?

Бэкап содержит не только данные. Он содержит всю структуру базы данных. Она включается в себя все данные, процедуры, представления, функции и весь остальной код. Также, он содержит все настройки БД. Наконец, он содержит всю информацию о пользователях БД. Для обычной БД, каждый пользователь БД связан с учётной записью SQL Server. Пароли таких пользователей хранятся вместе с учётной записью, так что этих паролей в бэкапе не будет.

Однако, в автономных базах данных (contained databases — прим. переводчика) существует понятие USER WITH PASSWORD, поскольку сама идея автономных баз данных предполагает минимальную связь такой базы с сервером. В этом случае, пароль будет находиться в бэкапе, что может привести к попыткам достать его оттуда. Пароли хранятся не открытым текстом, они хэшируются, точно так же как пароли учётных записей (которые хранятся в системной базе данных master и, естественно, попадают в её бэкап).

Microsoft предлагает несколько best practices по безопасности автономных баз данных.

Зачем в бэкапе индексы, статистика и остальные штуки, которые легко пересоздать? Это же просто потеря времени?

А по-моему, потеря времени – это попытки разделить вещи таким образом и делать резервную копию только одной части. Во-первых, как это сделать? Например, как забэкапить данные, не делая, при этом, бэкапа кластерных индексов? Это невозможно, поскольку листовой уровень кластерного индекса – это страницы данных. Т.е., можно сказать, что кластерные индексы – это сами таблицы, поэтому кластерные индексы должны быть включены в бэкап. Конечно, возможно выделить некластерные индексы в отдельную файловую группу и не делать её бэкап, но потом, после восстановления того бэкапа, что у нас есть, нам всё равно нужно будет возвращать эту файловую группу к жизни и перестраивать все индексы. Так чего мы добьёмся?

Со статистикой так же возникнут проблемы. SQL Server бэкапит статистику вместе с базой данных (и она занимает очень мало места, поскольку, гистограмма, называющаяся статистикой, строится всего лишь по 200 строкам) и восстанавливает её вместе с БД. Однако, если после восстановления мы начнём пересоздавать индексы, поскольку не делали их резервной копии, нам придётся пересоздавать и статистику. Это так же потребует дополнительного времени, а база данных, тем временем, будет оставаться недоступной.

В конце концов, я бы поспорил с формулировкой «легко пересоздать», поскольку в экстренном случае, весь этот процесс может оказаться очень запутанным, что неизбежно приведёт к тому, что люди, работающие с этой базой данных, не смогут получить к ней доступ намного большее время, чем в случае простого восстановления из бэкапа.

Сама идея создания резервной копии заключается в том, чтобы можно было восстановить базу данных как можно более быстро и эффективно. Чем сложнее процесс восстановления, тем менее эффективна резервная копия. Да, для хранения индексов, пользователей, хранимых процедур и всего прочего, требуется дополнительное пространство, но увеличение скорости восстановления за счёт того, что всё лежит в одном месте, стоит этого дополнительного пространства.

ОМГ! Я только что удалил таблицу! Я знаю, что это есть в журнале транзакций. Как мне её вернуть?

После того как транзакция была зафиксирована, SQL Server не сможет её откатить. Операции DELETE И TRUNCATE удаляют данные совершенно разными способами. Операция DELETE удаляет данные с помощью транзакций, удаляющих каждую строку. Операция TRUNCATE просто отмечает странницы данных, на которых лежали удаляемые данные, как не использующиеся. Но последствия ни одной из этих операций не могут быть устранены вручную при просмотре журнала транзакций. Вместо этого, вам нужно выполнить процесс, называющийся восстановлением на момент времени. Вы должны немедленно сделать бэкап журнала транзакций вашей БД для того, чтобы сохранить все изменения сделанные до того момента, как вы случайно удалили нужные данные из таблицы. Затем, вам нужно выполнить шаги, описанные в главе 6 этой книги для восстановления на момент времени (в MSDN тоже всё есть – прим. переводчика).

Другой вариант – использование сторонних утилит, типа SQL Backup Pro, которые могут выполнять восстановление отдельных объектов БД в режиме online из имеющихся резервных копий.

А если я просто хочу создать с помощью бэкапа скрипт для построения БД, без восстановления непосредственно бэкапа…?

Стандартных средств для создания такого скрипта в SQL Server не предусмотрено. Однако, утилиты, типа SQL Compare, могут сформировать его. Он легко создаётся с помощью GUI, но так же это возможно с использованием 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 так, как будто бы вы запускали процесс восстановления из этого бэкапа, но не требует использования всего того места, которое было бы необходимым при восстановлени. Примонтированный таким образом бэкап выглядит как самая обычная база данных и вы можете заскриптовать её любым удобным вам образом.

От переводчика:

Грант довольно активно пиарил утилиты своей компании на протяжении всей статьи, я постарался это немного сгладить. Названия остались, а если кому-то будут нужны ссылки – их достаточно легко найти в интернете (ну или спросить в личке у меня).

Как обычно, любые пожелания и исправления по переводу и стилистике приветствуются.

Создание и восстановление резервной копии базы данных в Microsoft SQL Server 2008 R2

В данной статье будет рассказано как вручную сделать полную резервную копию базы данных в SQL Server 2008 R2 с помощью программы «Среда Microsoft SQL Server Management Studio».

0. Оглавление

Создание резервной копии
Восстановление базы данных из резервной копии
Восстановление резервной копии в другую базу данных (копирование данных)

1. Создание резервной копии

На самом деле все довольно просто. Запускаем оснастку «Среда Microsoft SQL Server Management Studio» («Пуск» — «Все программы» — «SQL Server 2008 R2» — «Среда Microsoft SQL Server Management Studio» ) и вводим данные для авторизации.

После чего в Обозревателе объектов раскрываем вкладку «Базы данных» и кликнем правой кнопкой мыши по той базе данных, для которой необходимо сделать резервную копию. В появившемся контекстном меню выберем «Задачи» (Tasks) — «Создать резервную копию» (Back Up…) .

Запустится окно «Резервная копия базы данных» (Back Up Data Base) . Убедимся, что тип резервной копии стоит «Полная» (Full), при необходимости зададим имя и описание, а также укажем назначение резервной копии. По умолчанию выбран путь на жестком диске компьютера в папку Backup основного расположения баз SQL-сервера. Для того чтобы изменить место размещения копии, сначала нажмем «Удалить» (Remove), чтобы удалить существующее назначение, а затем «Добавить» (Add…) для добавления нового.

Здесь зададим расположение и имя файла резервной копии и нажмем «ОК» . Таких мест назначений можно задать несколько. В этом случае резервная копия будет разбита на равные части, каждая часть в указанном файле.

Далее перейдем на вкладку «Параметры» (Options), на которой можно можно указать, что резервную копию необходимо проверить после выполнения, а также задать другие параметры надежности.

Когда все настройки установлены, нажимаем «ОК» и дожидаемся завершения задачи. Если все сделано правильно, в указанной директории мы найдем файл резервной копии базы данных SQL.

2. Восстановление базы данных из резервной копии

Восстановление происходит по аналогичной схеме. В «Среде Microsoft SQL Server Management Studio» выбираем базу из которой сделана резервная копия, кликаем по ней правой кнопкой мыши, в контекстном меню выбираем «Задачи» (Tasks) — «Восстановить» (Restore) — «База данных…» (Database…).

Откроется окно «Восстановление базы данных» (Restore Database). Здесь, в качестве источника укажем «С устройства» (From device) и выберем файл резервной копии (созданных в пункте 1).

Установим флаг «Восстановить» (Restore) напротив выбранной резервной копии. При необходимости, на вкладке «Параметры» (Options), можно указать дополнительные параметры восстановления, о значении которых можно прочитать здесь.

После того, как все настройки сделаны, жмем «ОК» и дожидаемся сообщения об успешном восстановлении базы данных.

3. Восстановление резервной копии в другую базу данных (копирование данных)

Если же необходимо загрузить данные в базу данных, отличную от той из которой была сделана резервная копия, то при загрузке помимо действий, описанных в пункте 2, необходимо на вкладке «Параметры» (Options) задать имена файлов этой базы данных и установить флаг «Перезаписывать существующую базу данных» (WITH REPLACE).

Смотрите также:

Техподдержка: Настройка регулярного резервного копирования БД MS SQL Server

Рекомендуется настроить регулярное резервное копирование базы данных (на случай аппаратных или программных сбоев), причем лучше всего с сохранением резервных копий за последние несколько дней, например семь (за последнюю неделю).

Для этого можно использовать либо встроенный в SQL Server планировщик заданий – «SQL Server Agent» (в бесплатную версию не входит), либо стандартный «Планировщик Windows» в сочетании с утилитой SQLCMD.EXE, которая позволяет выполнять запросы к SQL Server из командной строки. В планировщике необходимо создать как минимум семь заданий (по одному на каждый день недели), каждое из которых будет (раз в неделю) заменять один из семи файлов, содержащих соответствующую резервную копию базы данных.

Кроме того, файлы резервных копий рекомендуется хранить не только на жестком диске компьютера, где установлен SQL Server, но и дублировать их на ленту или жесткий диск другого компьютера в сети. Для этого можно использовать либо специальное ПО, которое позволяет делать резервные копии всего диска, либо с помощью того же планировщика копировать файлы на ленту или другой компьютер (вторым шагом).

С помощью «Планировщика Windows» (для бесплатной версии)

Чтобы создать задание в «Планировщике Windows» надо:

Запустить программу «Блокнот» (Пуск->Все программы->Стандартные->Блокнот) и ввести следующие две строки, после чего сохранить их в виде командного файла (*.BAT):

SQLCMD -S (local) -E -Q «BACKUP DATABASE AltaSVHDb TO DISK = ‘D:\BACKUP\ AltaSVHDb_monday.bak’ WITH INIT, NOFORMAT, SKIP, NOUNLOAD»

XCOPY D:\BACKUP\ AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

где «(local)» – имя сервера (в случае установки именованного экземпляра SQL Server надо указать имя полностью: «ИМЯ_КОМПА\SQLEXPRESS»), «AltaSVHDb» – имя базы данных, «D:\BACKUP\ AltaSVHDb_monday.bak» – имя файла для создания в нем резервной копии (будет различаться по дням недели), «BACKUP_SERVER» – имя компьютера, на который будет выполняться дополнительное копирование, «Folder» – папка на этом компьютере (к ней должен быть предоставлен общий доступ).

Запустить мастер планирования заданий (Панель управления->Назначенные задания->Добавить задание) и нажать кнопку «Далее»:

Нажать кнопку «Обзор» и указать путь к командному файлу (*.BAT), созданному на шаге a):

Указать имя для задания, выбрать вариант запуска «еженедельно» и нажать кнопку «Далее»:

Поставить галочку возле нужного дня недели, а в поле «Время начала» указать время, когда должен запускаться процесс резервного копирования (обычно это делается ночью), затем нажать кнопку «Далее»:

Ввести имя пользователя и пароль (дважды) учетной записи ОС, от имени которой будет выполняться задание, и нажать кнопку «Далее»:

Внимание! Чтобы задание успешно выполнялось необходимо предоставить указанной здесь учетной записи (домена или локального компьютера) права записи в вышеупомянутую папку «\\BACKUP_SERVER\Folder», а также настроить доступ к самому SQL Server.

Нажать кнопку «Готово»

Примечание. Чтобы проверить работоспособность созданного задания, необходимо в списке заданий (Панель управления->Назначенные задания) нажать правой кнопкой мыши на интересующем задании и в контекстном меню выбрать пункт «Выполнить», затем убедиться, что файл резервной копии БД успешно создался по тем путям, которые были указаны на шаге a).

С помощью «SQL Server Agent» (в бесплатную версию не входит)

Чтобы создать задание в «SQL Server Agent» надо:

Запустить утилиту SQL Server Management Studio и подключиться к серверу под учетной записью администратора.

В левой части окна нажать правой кнопкой мыши на разделе «Объекты сервера/Устройства резервного копирования» и в контекстном меню выбрать пункт «Создать устройство резервного копирования»:

В поле «Имя устройства» ввести имя, которое будет ассоциироваться с файлом резервной копии БД, при необходимости изменить путь в поле «Файл» и нажать «ОК»:

В левой части окна нажать правой кнопкой мыши на разделе «Агент SQL Server/Задания» и в контекстном меню выбрать пункт «Создать задание»:

В поле «Имя» ввести имя задания:

На странице «Шаги» нажать кнопку «Создать»:

В появившемся окне ввести имя в поле «Имя шага», проверить, что в поле «Тип» выбрано «Сценарий Transact-SQL (T-SQL)», а в поле «Команда» ввести строку:

BACKUP DATABASE AltaSVHDb TO AltaSVHDb_monday WITH INIT, NOFORMAT, SKIP, NOUNLOAD

где «AltaSVHDb» – имя базы данных, «AltaSVHDb_monday» – имя устройства резервного копирования, созданного на шаге c) (будет различаться по дням недели):

В предыдущем окне нажать кнопку «ОК», в результате на странице «Шаги» должна появиться строка:

Чтобы файл резервной копии БД сразу копировался на другой компьютер в сети необходимо повторить пункты f) – h), в окне «Создание шага задания» выбрав в поле «Тип» значение «Операционная система (CmdExec)», а в поле «Команда» указав строку:

XCOPY D:\MSSQL\BACKUP\AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

где «D:\MSSQL\BACKUP\AltaSVHDb_monday.bak» – путь, указанный на шаге c) (будет различаться по дням недели), «BACKUP_SERVER» – имя компьютера, на который будет выполняться копирование, «Folder» – папка на этом компьютере (к ней должен быть предоставлен общий доступ):

Примечание. Чтобы копирование файла успешно выполнялось необходимо запускать «SQL Server Agent» под учетной записью домена Windows, для которой предоставлены права записи в вышеупомянутую папку (см. также «SQL2005_installation.doc» или «SQL2008_installation.doc»), а также настроен доступ к самому SQL Server (см. раздел «Настройка прав доступа к БД», включить эту учетную запись надо в роль «sysadmin» на странице «Серверные роли», а на страницах «Сопоставление пользователей» и «Защищаемые объекты» ничего не делать).

На странице «Расписания» нажать кнопку «Создать»:

Ввести имя в поле «Имя», проверить, что в поле «Тип расписания» выбрано значение «Повторяющееся задание», а в поле «Выполняется» – «Еженедельно». Поставить галочку возле нужного дня недели (остальные снять), а в поле «Однократное задание» указать время, когда должен запускаться процесс резервного копирования (обычно это делается ночью):

В предыдущем окне нажать кнопку «ОК», в результате на странице «Расписания» должна появиться строка:

Нажать кнопку «ОК».

Примечание. Чтобы проверить работоспособность созданного задания, необходимо в разделе «Агент SQL Server/Задания» нажать правой кнопкой мыши на интересующем задании и в контекстном меню выбрать пункт «Запустить задание на шаге», в появившемся окне выбрать первый шаг данного задания и нажать «ОК». Далее появится окно отображающее ход выполнения задания. Если выполнение задания закончится с ошибкой, то подробное описание ошибки можно увидеть вызвав пункт «Просмотр журнала» того же контекстного меню.

SQL Server 2008: бэкапим с умом. Часть 1: Теория / Хабр

Добрый день, друзья. В этой статье я хотел бы рассказать, о чем стоит задуматься, прежде чем настраивать систему резервного копирования баз данных. Несмотря на то, что в первую очередь рассматривается использование данного подхода с MS SQL Server, принципы, изложенные здесь, легко проецируются на любую другую технологию. Ну что ж, поехали.

Первые шаги

Если так уж сложилось, что по долгу своей службы вы отвечаете за сохранность баз данных и бесперебойное функционирование SQL-сервера, то наверняка первой вещью, о которой вы задумаетесь, будут бэкапы — банально по той причине, что если вдруг с вашими базами данных случается какая-нибудь беда, а у вас нет бэкапа, вас ждет не самое приятное будущее. Но вместе со светлой мыслью о необходимости бэкапов приходит и миллион самых разнообразных вопросов: с чего начать? резервировать все базы вместе, или лучше каждую отдельно? делать полный бэкап? А может, лучше резервировать только логи? Что ж, давайте попробуем разобраться.

В первую очередь следует определиться с двумя фундаментальными вопросами:

Насколько велика роль каждой отдельной базы данных для компании? и

Потери данных за какой промежуток времени можно считать допустимыми?

С первым вопросом все более-менее ясно — он нужен для того, чтобы определиться с глобальной стратегией. Очевидно, что чем важнее какая-то конкретная база данных, тем раньше и чаще для нее должны делаться бэкапы. Если в компании все базы данных используются примерно с одинаковой степенью интенсивности, то оптимальным вариантом скорее всего будет создание единого плана резервирования. С другой стороны, если у вас одни базы данных используются намного чаще и нагружены значительно сильнее, чем другие, возможно, стоит задуматься о том, чтобы планировать их резервирование независимо друг от друга.

А вот со вторым вопросом все не так гладко. Хотя бы потому, что в ответ абсолютное большинство руководителей расскажет вам о недопустимости потери данных за любой промежуток времени. Между тем, все мы прекрасно понимаем, что организация отказостойчивой инфраструктуры со сведенным к нулю шансом потери данных — дело сложное, затратное и неподходящее для небольших и средних компаний. Постарайтесь объяснить свою позицию и добиться какого-то более определенного ответа — день, час, полчаса, пять минут или любая другая цифра, с которой вы сможете работать.

Только тогда, когда у вас будут конкретные и однозначные ответы на эти вопросы, вы сможете правильно оценить плюсы и минусы различных подходов к созданию бэкапов.

Full Backup

Полный бэкап — это фундамент, на котором будет держаться вся ваша система резервирования. По большому счету, это копия базы данных, которая включает в себя вообще все — таблицы, данные, индексы, триггеры, статистику, хранимые процедуры и еще много разного добра. Более того — если вы выбираете вариант динамического резервного копирования (то есть во время резервирования данных пользователи могут полноценно работать с сохраняемой БД), то все измения, которые пользователи сделают за то время, пока создается бэкап, тоже будут сохранены. Вы можете легко вернуть базу данных к тому состоянию, в котором она была в какой-то определенный момент, если у вас есть полный бэкап, сделанный в это время.

Главный вопрос, связанный с полными бэкапами — как часто их стоит делать? Универсального ответа нет. Понятно, что полное резервирование должно выполняться по меньшей мере раз в неделю. Если у вас не слишком большие базы данных и нет особых проблем с местом под бэкапы, возможно, резервирование раз в день будет более подходящим вариантом. С другой стороны, слишком частое полное резервирование будет нагружать ваш сервер и потребует неоправданно много дискового пространства для хранения бэкапов. Точная цифра зависит от размера ваших баз данных, производительности и загруженности сервера, ответа на «фундаментальный вопрос номер два» и того, как часто вы будете делать бэкапы других типов, например, бэкап лога или дифференцированный бэкап.

Log backup

Бэкап лога отличается от полного бэкапа тем, что в него входят исключительно изменения базы данных (то есть операции INSERT, UPDATE и DELETE) с момента последнего бэкапа, будь то полный бэкап, дифференцированный или предыдущий бэкап лога. Поскольку объем сохраняемых данных крайне мал, такой тип резервирования намного быстрее, требует меньше ресурсов и занимает меньше места на диске. Недостатков, увы, тоже хватает. В первую очередь, бэкап лога бесполезен, если у вас нет хотя бы одного полного бэкапа. Объясняется это тем, что в таком логе не сохраняется никакая информация о таблицах, индексах, хранимых процедурах и так далее. Вторым существенным недостатком является то, что если с момента последнего полного бэкапа вы успели сделать сотню бэкапов лога, а потом случилась беда, то прежде, чем вы восстановите заветный сотый, вам потребуется восстановить не только полный бэкап, но и предыдущие девяносто девять бэкапов лога, да к тому же в правильном порядке. Согласитесь, приятного в такой перспективе не очень много. Еще одна немаловажная особенность заключается в том, что бэкап лога доступен только для тех баз данных, у которых указан FULL или BULK LOGGED режим восстановления.

Для того, чтобы можно было создавать бэкапы лога, ведение этого самого лога должно быть включено. Хотя данная опция работает по умолчанию и предоставляет немало замечательных возможностей, есть ситуации, когда разумнее будет отказаться от ее использования. Во-первых, лучше отключить ведение лога, если вы собираетесь добавить в базу или изменить в ней очень много данных. Такая операция может занять не один час, но с отключенным протоколированием выполнится намного быстрее. Как только данные будут добавлены, можно смело делать полный бэкап БД и включать режим ведения лога. Вторым пикантным моментом является то, что за логом нужно очень пристально следить — если память, которая доступна для записи лога, заканчивается, система останавливает все выполняющиеся транзакции до тех пор, пока память не будет освобождена. Чтобы избежать такой печальной ситуации, требуется делать бэкап лога как можно чаще — тогда как только вы делаете более свежий бэкап, система помечает сохраненную порцию лога как доступную для перезаписи, тем самым восстанавливая занятое дисковое пространство.

Как часто делать бэкапы лога? Опять же, универсального ответа нет. С одной стороны, чем чаще вы делаете бэкап лога, тем большую гибкость получаете при восстановлении и тем меньше данных теряете в случае каких-то происшествий. С другой стороны, если вы делаете полный бэкап раз в сутки, а бэкап лога раз в минуту, то при худших раскладах вам придется восстановить почти полторы тысячи бэкапов, прежде чем база вернется к тому состоянию, которое можно считать последним рабочим. Мало того, что такая перспектива сама по себе не вдохновляет на подвиги, так еще и в это время над вами будут стоять руководители, директора и все, кому не лень, спрашивая о том, когда же всё будет готово и почему так долго. Думаю, бэкап лога чаще, чем раз в пять минут, практически всегда окажется плохой идеей. Существует мнение, что бэкап лога реже, чем раз в час, тоже не имеет смысла, но это заявление кажется мне несколько спорным. В любом случае, если вы будете держаться в этих пределах, скорее всего, это станет неплохим решением.

Differential Backup

Дифференцированный бэкап — это что-то среднее между полным бэкапом и бэкапом лога. В нем сохраняются изменения, сделанные с момента последнего полного бэкапа по настоящее время. Главным его преимуществом по сравнению с бэкапом лога является то, что для полного восстановления базы данных вам достаточно восстановить только лишь полный и последний дифференцированный бэкапы. Недостатком же является то, что вы не можете восстановить промежуточное состояние базы данных на какой-то момент времени — история изменения БД в дифференцированном бэкапе не сохраняется. Как и бэкап лога, такой бэкап бесполезен, если у вас нет полной копии базы данных.

Вместо постскриптума

Напоследок я хотел бы дать вам несколько советов, которым не нашлось места в рамках основного повествования, но которые слишком важны, чтобы о них молчать.

Используйте DBCC CHECKDB для проверки каждой базы данных перед копированием, это своевременно предупредит вас о надвигающихся проблемах.

Используйте опцию BACKUP WITH CHECKSUM, чтобы убедиться, что все прошло хорошо. Недостатком такого решения является то, что для больших баз данных проверка контрольной суммы может серьезно загрузить систему.

Если у вас проблемы с дисковым пространством, доступным для хранения бэкапов, используйте опцию BACKUP WITH COMPRESSION. Сжатие позволяет уменьшить итоговый размер файла с бэкапом в несколько раз, обычно в 3-5. Как и в случае с проверкой контрольной суммы, такая операция очень серьезно влияет на производительность, особенно для больших баз данных. Помните, что опция сжатия доступна только для Enterprise-версии SQL Server 2008 и Enterprise и Standart-версий 2008R2. Все другие версии, в том числе девелоперские, не смогут ни сжать бэкап при резервировании, ни «разжать» при восстановлении.

Создавайте отдельный файл для каждого бэкапа, не храните все бэкапы в одном файле. В таком случае, если с этим файлом что-то случится, вы потеряете один бэкап, а не все.

Естественно, не храните бэкап на том же диске, на котором хранится ваша БД.

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

Автоматизируйте процесс создания бэкапов. Это просто, и вы будете уверены, что у вас всегда есть свежая копия базы данных.

Бэкапы бесполезны, если вы не можете их использовать. Поэтому регулярно тренируйтесь в восстановлении баз данных, чтобы при необходимости вы могли в стрессовой ситуации сделать все быстро и безошибочно.

На этом, пожалуй, всё. Хочу сразу заметить, что в рамках данной статьи я намеренно не рассматривал такие моменты, как бэкап файлов, бэкап без очистки лога и многое другое. В следующий раз я постараюсь сделать более «практическую» статью, рассказать о различных путях автоматизации создания резервных копий и привести примеры кода. Надеюсь, вы почерпнули что-то новое и полезное для себя. Have a nice day.

Разбираемся с утилитами для бэкапа баз данных — «Хакер»

Содержание статьи

Серверы баз данных — одни из ключевых в любой организации. Именно они хранят информацию и предоставляют выдачу по запросу, и крайне важно сохранить БД в любой ситуации. Базовая поставка обычно включает нужные утилиты, но админу, не сталкивавшемуся до этого с БД, придется некоторое время разбираться с особенностями работы, чтобы обеспечить автоматизацию.

Виды бэкапов баз данных

Для начала разберемся с тем, какие вообще бывают бэкапы. Сервер баз данных не является обычным десктопным приложением, и, чтобы обеспечить выполнение всех свойств ACID (Atomic, Consistency, Isolated, Durable), используется ряд технологий, а поэтому создание и восстановление БД из архива имеет свои особенности. Существуют три различных подхода к резервному копированию данных, каждый из которых имеет свои плюсы и минусы.

При логическом, или SQL, бэкапе (pg_dump, mysqldump, SQLCMD) создается мгновенный снимок содержимого базы с учетом транзакционной целостности и сохраняется в виде файла с SQL-командами (можно выбрать всю базу или отдельные таблицы), при помощи которого можно воссоздать базу данных на другом сервере. На это требуется время (особенно для больших баз) для сохранения и восстановления, поэтому очень часто эту операцию выполнять нельзя и ее производят во время минимальной нагрузки (например, ночью). При восстановлении администратору необходимо будет выполнить несколько команд, чтобы подготовить все необходимое (создать пустую базу данных, учетные записи и прочее).

Физический бэкап (уровня файловой системы) — копирование файлов, которые СУБД использует для хранения данных в базе данных. Но при простом копировании игнорируются блокировки и транзакции, которые, скорее всего, будут неправильно сохранены и нарушены. При попытке присоединить этот файл он будет в несогласованном состоянии и приведет к ошибкам. Чтобы получить актуальный бэкап, базу данных нужно остановить (можно уменьшить время простоя, использовав два раза rsync — вначале на работающей, потом на остановленной). Недостаток этого метода очевиден — нельзя восстановить определенные данные, только всю базу данных. При старте БД, восстановленной из архива файловой системы, нужно будет провести проверку на целостность. Здесь используются разные вспомогательные технологии. Например, в PostgreSQL логи упреждающей журнализации WAL (Write Ahead Logs) и специальная функция (Point in Time Recovery — PITR), позволяющая вернуться к определенному состоянию базы. С их помощью легко реализуется третий сценарий, когда бэкап уровня файловой системы объединяется с резервной копией WAL-файлов. Вначале восстанавливаем файлы резервной копии файловой системы, а затем при помощи WAL база приводится к актуальному состоянию. Это чуть более сложный подход для администрирования, но зато нет проблем с целостностью БД и восстановлением баз до определенного времени.

Логический бэкап используется в тех случаях, когда необходимо одноразово сделать полную копию базы или в повседневной эксплуатации для создания копии не потребуется много времени или места. Когда же выгрузка баз занимает много времени, следует обратить внимание на физическое архивирование.

Barman

Сайт: pgbarman.org, sf.net/projects/pgbarman

Лицензия: GNU GPL

Поддерживаемые СУБД: PostgreSQL

PostgreSQL поддерживает возможности физического и логического бэкапа, добавляя к ним еще один уровень WAL (см. врезку), который можно назвать непрерывным копированием. Но управлять при помощи штатных инструментов несколькими серверами не очень удобно даже админу со стажем, а в случае сбоя счет идет на секунды.

Barman (backup and recovery manager) — внутренняя разработка компании 2ndQuadrant, предоставляющей услуги на базе PostgreSQL. Предназначен для физического бэкапа PostgreSQL (логический не поддерживает), архивирования WAL и быстрого восстановления после сбоев. Поддерживаются удаленный бэкап и восстановление нескольких серверов, функции point-in-time-recovery (PITR), управление WAL. Для копирования и подачи команд на удаленный узел используется SSH, синхронизация и бэкап при помощи rsync позволяет сократить трафик. Также Barman интегрируется со стандартными утилитами bzip2, gzip, tar и подобными. В принципе, можно использовать любую программу сжатия и архивирования, интеграция не займет много времени. Реализованы различные сервисные и диагностические функции, позволяющие контролировать состояние сервисов и регулировать полосу пропускания. Поддерживаются Pre/Post-скрипты.

Конфигурационный файл Barman

Barman написан на Python, управление политиками резервного копирования производится при помощи понятного INI-файла barman.conf, который может находиться в /etc или домашнем каталоге пользователя. В поставке идет готовый шаблон с подробными комментариями внутри. Работает только на *nix-системах. Для установки в RHEL, CentOS и Scientific Linux следует подключить EPEL — репозиторий, в котором содержатся дополнительные пакеты. В распоряжении пользователей Debian/Ubuntu официальный репозиторий:

$ sudo apt-get install barman

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

Sypex Dumper

Сайт: sypex.net/ru/products/dumper

Лицензия: BSD

Поддерживаемые СУБД: MySQL

Вместе с MySQL поставляются утилиты mysqldump, mysqlhotcopy, позволяющие легко создать дамп базы данных, они хорошо документированы, и в интернете можно найти большое количество готовых примеров и фронтендов. Последние позволяют новичку быстро приступить к работе. Sypex Dumper представляет собой PHP-скрипт, позволяющий легко создать и восстановить копию базы данных MySQL. Создавался для работы с большими базами данных, работает очень быстро, понятен и удобен в использовании. Умеет работать с объектами MySQL — представлениями, процедурами, функциями, триггерами и событиями.

Еще один плюс, в отличие от других инструментов, при экспорте производящих перекодирование в UTF-8, — в Dumper экспорт производится в родной кодировке. Результирующий файл занимает меньше места, а сам процесс происходит быстрее. В одном дампе могут быть объекты с разными кодировками. Причем легко импорт/экспорт произвести в несколько этапов, останавливая процесс во время нагрузки. При возобновлении процедура начнется с места остановки. При восстановлении поддерживается четыре варианта:

CREATE + INSERT — стандартный режим восстановления;
TRUNCATE + INSERT — меньше времени на создание таблиц;
REPLACE — восстанавливаем в рабочей базе старые данные, не затирая новые;
INSERT IGNORE — добавляем в базу удаленные или новые данные, не трогая существующие.

Поддерживается сжатие копии (gzip или bzip2), автоудаление старых бэкапов, реализован просмотр содержимого дамп-файла, восстановление только структуры таблиц. Имеются и сервисные функции по управлению БД (создание, удаление, проверка, восстановление БД, оптимизация, очистка таблиц, работа с индексами и другое), а также файл-менеджер, позволяющий копировать файлы на сервер.

Интерфейс Dumper

Управление производится при помощи веб-браузера, интерфейс с использование AJAX локализован из коробки и создает впечатление работы с настольным приложением. Также возможно запускать задания из консоли и по расписанию (через cron).

Для работы Dumper понадобится классический L|WAMP-сервер, установка обычная для всех приложений, написанных на PHP (копируем файлы и устанавливаем права), и не будет сложной даже для новичка. Проект предоставляет подробную документацию и видеоуроки, демонстрирующие работу с Sypex Dumper.

Есть две редакции: Sypex Dumper (бесплатно) и Pro (10 долларов). Вторая имеет больше возможностей, все отличия приведены на сайте.

SQL Backup And FTP

Сайт: sqlbackupandftp.com

Лицензия:коммерческая, есть версия Free

Поддерживаемые СУБД: MS SQL Server

MS SQL Server — одно из популярных решений, а потому встречается достаточно часто. Задание резервного копирования создается при помощи среды SQL Server Management Studio, собственно Transact-SQL и командлетов модуля SQL PowerShell (Backup-SqlDatabase). На сайте MS можно найти просто огромное количество документации, которая позволяет разобраться с процессом. Документация хотя и полная, но очень специфическая, а информация в интернете часто противоречит друг другу. Новичку действительно вначале потребуется потренироваться, «набив руку», поэтому, даже несмотря на все сказанное, сторонним разработчикам есть где развернуться. К тому же бесплатная версия SQL Server Express не может похвастаться встроенными инструментами для резервного копирования. Для более ранних версий MS SQL (до 2008) можно найти бесплатные утилиты, например SQL Server backup, но в большинстве подобные проекты уже коммерциализировались, хотя и предлагают всю функциональность часто за символическую сумму.

SQL Backup And FTP позволяет одним щелчком произвести бэкап MS SQL

Например, разработка SQL Backup And FTP и One-Click SQL Restore соответствует принципу «настроил и забыл». Обладая очень простым и понятным интерфейсом, они позволяют создавать копии баз данных MS SQL Server (включая Express) и Azure, сохранять зашифрованные и сжатые файлы на FTP и облачных сервисах (Dropbox, Box, Google Drive, MS SkyDrive или Amazon S3), результат можно тут же просмотреть. Возможен запуск процесса как вручную, так и по расписанию, отправка сообщения о результате задания по email, запуск пользовательских скриптов.

Поддерживаются все варианты бэкапа: полный, дифференциальный, журнал транзакций, копирование папки с файлами и многое другое. Старые резервные копии удаляются автоматически. Для подключения к виртуальному узлу используется SQL Management Studio, хотя здесь могут быть нюансы и это будет работать не во всех таких конфигурациях. Для загрузки предлагается пять версий — от бесплатной Free до навороченной Prof Lifetime (на момент написания этих строк стоила всего 149 долларов). Функционала Free вполне достаточно для небольших сетей, в которых установлено один-два SQL-сервера, все основные функции активны. Ограничено количество резервных БД, возможность отправки файлов на Google Drive и SkyDrive и шифрование файлов. Интерфейс хотя и не локализован, но очень прост и понятен даже новичку. Нужно лишь подключиться к SQL-серверу, после чего будет выведен список баз данных, следует отметить нужные, настроить доступ к удаленным ресурсам и указать время выполнения задания. И все это в одном окне.

Но есть одно «но». Сама программа не предназначена для восстановления архивов. Для этого предлагается отдельная бесплатная утилита One-Click SQL Restore, понимающая и формат, созданный командой BACKUP DATABASE. Админу необходимо лишь указать архив и сервер, на который восстановить данные, и нажать одну кнопку. Но в более сложных сценариях придется использовать RESTORE.

Утилита One-Click SQL Restore предназначена для восстановления баз MS SQL

Особенности бэкапа MS SQL Server

Создание резервной копии и восстановление СУБД имеет свои отличия, которые нужно учитывать, особенно их много при переносе архива на другой сервер. Для примера разберем некоторые нюансы MS SQL Server. Для архивирования при помощи Transact-SQL следует использовать команду BACKUP DATABASE (есть и разностная DIFFERENTIAL) и журнал транзакций BACKUP LOG.

Если резервная копия разворачивается на другом сервере, нужно убедиться, что присутствуют те же самые логические диски. Как вариант — можно вручную прописать правильные пути для файлов базы данных, используя опцию WITH MOVE команды RESTORE DATABASE.

Простая ситуация — бэкап и перенос баз на другие версии SQL Server. Эта операция поддерживается, но в случае SQL Server будет работать, если версия сервера, на которой разворачивается копия, такая же или новее, чем та, на которой она создавалась. Причем есть ограничение: новее не более чем на две версии. После восстановления БД будет находиться в режиме совместимости с той версией, с которой осуществлялся переход, то есть новые функции будут недоступны. Это легко поправить, изменив COMPATIBILITY_LEVEL. Можно это сделать при помощи GUI или SQL.

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Определить, на какой версии была создана копия, можно, просмотрев заголовок файла архива. Чтобы не экспериментировать, при переходе на новую версию SQL Server следует запустить бесплатную утилиту Microsoft Upgrade Advisor.

Iperius

Сайт: iperiusbackup.com

Лицензия:коммерческая, есть версия Free

Поддерживаемые СУБД: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL и MS SQL Server

Когда приходится управлять несколькими типами СУБД, без комбайнов не обойтись. Выбор большой. Например, Iperius — легкая, очень простая в использовании и одновременная мощная программа для резервного копирования файлов, имеющая функцию горячего резервирования баз данных без прерывания в работе или блокирования. Обеспечивает полный или инкрементальный бэкап. Может создавать полные образы дисков для автоматической переустановки всей системы. Поддерживает резервное копирование на NAS, USB-устройства, стример, FTP/FTPS, Google Drive, Dropbox и SkyDrive. Поддерживает сжатие zip без ограничения в размере файлов и AES256-шифрование, запуск внешних скриптов и программ. Включает весьма функциональный планировщик заданий, возможно параллельное или последовательное выполнение нескольких заданий, результат отправляется на email. Поддерживаются многочисленные фильтры, переменные для персонализации путей и настроек.

Настройка задания в Iperius

Возможность закачки по FTP позволяет легко обновлять информацию на нескольких веб-сайтах. Открытые файлы резервируются при помощи технологии VSS (теневого копирования томов), что позволяет производить горячий бэкап не только файлов СУБД, но и других приложений. Для Oracle также задействуется средство организации резервного копирования и восстановления данных RMAN (Recovery Manager). Чтобы не перегружать канал, есть возможность настройки полосы пропускания. Управление резервированием и восстановлением производится при помощи локальной и веб-консоли. Все функции на виду, поэтому для настройки задания потребуется лишь понимание процесса, в документацию заглядывать даже не придется. Просто следуем подсказкам мастера. Также можно отметить менеджер учетных записей, что очень удобно при большом количестве систем.

Базовые функции предлагаются бесплатно, но возможность резервирования БД заложена только в версиях Advanced DB и Full. Поддерживается установка от XP до Windows Server 2012.

Handy Backup

Сайт: handybackup.ru

Лицензия:коммерческая

Поддерживаемые СУБД:Oracle, MySQL, IBM DB2 (7–9.5) и MS SQL Server

Одна из самых мощных систем управления реляционными базами данных — IBM DB2, имеющая уникальные функции по масштабированию и поддерживающая множество платформ. Поставляется в нескольких редакциях, которые построены на одной базе и отличаются функционально. Архитектура баз данных DB2 позволяет управлять практически всеми типами данных: документами, XML, медиафайлами и так далее. Особо популярна бесплатная DB2 Express-C. Бэкап очень прост:

db2 backup db sample

Или снапшот, использующий функцию Advanced Copy Services (ACS):

db2 backup db sample use snapshot

Но нужно помнить, что в случае снимков мы не можем восстанавливать (db2 recover db) отдельные таблицы. Есть и возможности по автоматическому бэкапу, и многое другое. Продукты хорошо документированы, хотя в русскоязычном интернете руководства встречаются редко. Также далеко не во всех специальных решениях можно найти поддержку DB2.

Например, Handy Backup позволяет выполнять бэкап нескольких типов серверов баз данных и сохранять файлы практически на любой носитель (жесткий диск, CD/DVD, облачное и сетевое хранилище, FTP/S, WebDAV и другие). Возможен бэкап баз данных через ODBC (только таблицы). Это одно из немногих решений, поддерживающих DB2, и к тому же имеет логотип «Ready for IBM DB2 Data Server Software». Вся процедура выполняется при помощи обычного мастера, в котором необходимо лишь выбрать нужный пункт и сформировать задачу. Сам процесс настройки настолько прост, что разобраться сможет и новичок. Можно создать несколько заданий, которые будут запускаться по расписанию. Результат фиксируется в журнале и отправляется по email. Во время работы задания остановка сервиса не требуется. Архив автоматически сжимается и шифруется, что гарантирует его безопасность.

Работа мастера создания нового задания в Handy Backup

Работу с DB2 поддерживают две версии Handy Backup — Office Expert (локальный) и Server Network (сетевой). Работает на компьютерах под управлением Win8/7/Vista/XP или 2012/2008/2003. Сам процесс развертывания несложен для любого админа.

Создание резервной копии базы данных в MS SQL Server 2012

Ниже будет подробно рассказано о том, как создать резервную копию базы данных в MS SQL Server 2012. В младших версиях (например в MS SQL Server 2008) алгоритм получения резервной копии аналогичен.

0. Оглавление

Создание резервной копии базы данных
Просмотр информации о событиях резервного копирования и восстановления для базы данных

1. Создание резервной копии базы данных

Запускаем утилиту «SQL Server Management Studio». В Microsoft Windows Server 2012 (R2) ее можно найти в списке всех программ.

В Microsoft Windows Server 2008 (R2) в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Среда SQL Server Management Studio».

Вводим адрес сервера или его псевдоним, данные для авторизации и нажимаем «Соединить» (Connect).

Затем в обозревателе объектов (Object Explorer) раскрываем вкладку «Базы данных» (Databases), кликаем правой кнопкой мыши по базе, из которой необходимо выгрузить данные и в контекстном меню выбираем «Задачи» (Tasks) — «Создать резервную копию…» (Back up…).

Откроется окно настройки свойств резервного копирования базы данных. Здесь можно выбрать:

Базу данных (Database) для которой создается резервная копия — выбрана база данных с которой мы начинали действия.
Тип резервной копии (Backup type) — по умолчанию полная (Full). Подробно о различных типах резервных копий читайте здесь.
Установить флаг «Только резервная копия» (Copy-only Backup) — признак того, что создаваемая резервная копия будет изолирована от обычной последовательности резервных копий SQL Server.
Компоненты резервного копирования (Backup component) — всю базу данных (Database) или только выбранные файлы (Files and filegroups).
Срок действия резервного набора данных (Backup set will expire) — период, после которого эта резервная копия может быть перезаписана без явного пропуска проверки на истечение срока. Если выбрано через 0 дн. (After: 0 days), файлы резервной копии не будут перезаписываться.
Назначение (Destination) — путь к файлу резервной копии на выбранном диске (Disk).

Для того, чтобы изменить или добавить место расположения и имя файла резервной копии или устройства резервного копирования, нажмем «Добавить» (Add…), в окне выбора места расположения резервной копии выберем каталог и имя файла, и закроем все окна нажав «ОК». Для удаления назначения резервного копирования, выделим его в списке и воспользуемся кнопкой «Удалить» (Remove).

Определившись с общими настройками резервного копирования переходим на вкладку «Параметры» (Options).

Здесь установим флаг «Проверить резервную копию после завершения» (Verify backup when finished) для обеспечения больше надежности и установим параметр «Сжимать резервные копии» (Compress backup) для экономии дискового пространства, после чего нажмем «ОК» для запуска процесса создания файла резервной копии.

Если резервное копирование выбранной базы данных завершилось успешно, увидим соответствующее сообщение.

Ну а в указанном ранее каталоге найдем непосредственно сам файл резервной копии выбранной базы данных.

О восстановлении базы данных из резервной копии, можно прочитать в статье «Восстановление базы данных из резервной копии в MS SQL Server 2012»

2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).

Сформировавшийся отчет содержит в себе следующие данные:

Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
Успешные операции резервного копирования (Saccessful Backup Operations)
Ошибки операции резервного копирования (Backup Operation Errors)
Успешные операции восстановления (Saccessful Restore Operations)

Для просмотра данной информации необходимо раскрыть соответствующую группировку в отчете.

Смотрите также:

Добавление базы данных в Microsoft SQL Server 2012
Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…
Отсоединение и Присоединение баз данных в MS SQL Server 2012
В ситуации когда необходимо перенести базу данных SQL с одного экземпляра MS SQL Server на другой, или изменить каталог хранения файлов базы данных, помогут операции отсоединения (Detach) и присоединения (Attach) баз данных MS SQL Server.…

MS SQL SERVER EXPRESS

sql. , —

SQL Management Studio,. -:

, «» (Полный),,. Резервное копирование SQL-. , «» (Удалить),, «» (Добавить…).

«» (Опции),,,. «»:

  - путь -,
- 1 -
объявить @path varchar (max) = N'F: \ Backup \ DATABASE_NAME_backup _ '+ convert (varchar (max), getdate (), 112) + N'.бак '
РЕЗЕРВНАЯ БАЗА ДАННЫХ [erp_base] НА ДИСК = @path С NOFORMAT, NOINIT, NAME = N'erp_base- ', SKIP, NOREWIND, NOUNLOAD, STATS = 10
ИДТИ
- 2 -
объявить @backupSetId как int
объявить @path varchar (max) = N'F: \ Backup \ DATABASE_NAME_backup _ '+ convert (varchar (max), getdate (), 112) + N'.bak'
выберите @backupSetId = position from msdb..backupset, где database_name = N'erp_base 'и backup_set_id = (выберите max (backup_set_id) из msdb..backupset, где database_name = N'erp_base')
если @backupSetId имеет значение null, начало raiserror (N '."erp_base". ', 16, 1) конец
ВОССТАНОВИТЬ ТОЛЬКО С ДИСКА = @path С ФАЙЛОМ = @backupSetId, NOUNLOAD, NOREWIND
GO

DATABASE_NAME,.

кв. –:

cmd:

del «F: \ Backup \ log.txt»
sqlcmd -S SERVER-2008R2 \ SQLEXPRESS -i F: \ Backup \ backup_script_erp_base.sql -o «F: \ Backup \ log.txt»
выход

СЕРВЕР-2008R2 \ SQLEXPRESS — \
backup_script_erp_base -,
F: \ Backup \ log.txt -. ,.

: 2. -. — log.txt.

окон. Win + R () taskschd.msc:

–:

, «» «».

create_backup_erp_base.bat, .

ОК. :

MS SQL Server Express.

, MS SQL Server Express.

Запланированное автоматическое резервное копирование базы данных SQL с использованием SSMS

Это следующие шаги, которые необходимо выполнить, чтобы создать файл .bak (резервную копию) с помощью SSMS:
Для автоматизации и планирования резервного копирования с помощью агента SQL Server:

Откройте свой SQL-сервер Management Studio

Войдите в SQL Server Management Studio (SSMS) и подключитесь к базе данных. Перейдите в окно обозревателя объектов (расположенное слева) и убедитесь, что ваш агент SQL Server запущен.

Откройте папку Management и найдите папку с планом обслуживания. Затем щелкните правой кнопкой мыши папку «План обслуживания» и выберите «Новый план обслуживания». Как сделать резервную копию базы данных SQL автоматически

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

Теперь выберите в левом окне, выберите задачу резервного копирования базы данных, чтобы настроить процесс резервного копирования, и перетащите элемент в правое окно, как показано на рисунке.

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

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

Теперь в Обозревателе объектов> Агент SQL Server> Задания
в разделе заданий агента SQL мы можем найти задание, созданное автоматически в соответствии с планом обслуживания, который мы создали.

Щелкните это задание правой кнопкой мыши и нажмите Начать задание на шаге, чтобы протестировать план обслуживания, который мы создали ранее,

Теперь перейдем к файлу резервной копии, который мы определили ранее, чтобы проверить резервную копию,

Выпуски

SQL Server Express не позволяют планировать задания или планы обслуживания, поскольку компонент агента SQL Server не включен в эти выпуски.Следовательно, при использовании этих выпусков необходимо учитывать другой подход к резервному копированию баз данных.

В настоящее время пользователи SQL Server Express могут создавать резервные копии своих баз данных, используя один из следующих методов:

Используйте SQL Server Management Studio Express. Он устанавливается вместе с SQL Server Express Advanced Service или SQL Server Express Toolkit.
Используйте сценарий Transact-SQL, который использует семейство команд BACKUP DATABASE.

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

План обслуживания также является атомарным и поэтому не может выполнять несколько задач. Каждый тип задачи обслуживания в рамках одного плана обслуживания может быть настроен для выполнения только один раз в рамках этого плана. Например, если задача состоит в удалении старых файлов резервных копий, она будет удалять только файлы одного типа за раз. Из-за этого в некоторых случаях необходимо создать несколько планов обслуживания только для выполнения одной задачи, и в каждом плане обслуживания должно быть запланировано соответствующее задание агента SQL Server.

Вот и все, ваш план резервного копирования готов, и все ваши резервные копии будут делаться по заданному расписанию. Теперь вы знаете, как автоматически создавать резервные копии базы данных SQL.

Надеюсь, это поможет,

Кенан ДЖАДДЕН

SQL Backup Бесплатно | Бесплатная резервная копия MS SQL Server

Резервное копирование баз данных SQL в облака SkyDrive или Box с помощью SQLBackupAndFTP

Размещено Алексеем 29 июля, 2013 г.

Чтобы ваша база данных SQL Server оставалась защищенной от сбоев компьютеров, вам следует периодически создавать резервные копии ваших баз данных SQL Server. Все ваши резервные копии должны быть доступны вам всегда и везде. Резервное копирование баз данных в облако дает такие преимущества, как доступность, надежность и простота.SQLBackupAndFTP — это простой инструмент, который можно использовать для резервного копирования и сжатия баз данных и их сохранения в разных местах назначения. Теперь у вас есть возможность сохранять резервные копии в облаках SkyDrive и Box, и это действительно просто! Вам не нужно устанавливать какой-либо конкретный драйвер, другое приложение этих облаков, просто установите SQLBackupAndFTP, выберите базы данных, для которых вы хотите создать резервную копию, и подключите их к своим облакам. Хотя место назначения SkyDrive доступно в стандартной версии SQLBackupAndFTP или выше, в настоящее время они проводят очень редкую акцию: 5–9 лицензий: 20% скидка 10–19 лицензий: скидка 35%, более 20 лицензий: скидка 50% Хотя резервное копирование до SkyDrive доступен в платной версии приложения, мы можем попробовать его в пробном режиме.Пункт назначения коробки доступен в бесплатной версии. Давайте теперь посмотрим, как мы можем сделать резервную копию и переместить ее в ваше облако SkyDrive. Если у вас все еще нет этого инструмента, просто загрузите его на странице загрузки и установите. Выбор баз данных для резервного копирования Сначала давайте выберем наши базы данных, для которых мы хотим создать резервную копию. Как видите, все настройки очень просты, как показано на следующем изображении. Просто запустите приложение, нажмите кнопку «Подключиться к SQL Server», введите параметры подключения в форме «Подключиться к SQL Server», нажмите кнопку «Сохранить и закрыть», и вы сможете выбрать свои базы данных в главной форме….

Учить больше

Как написать политику доступа к Amazon S3 с минимальным разрешением, необходимым для резервного копирования баз данных с помощью SQLBackupAndFTP

Написал Алексей 26 июля, 2013

Многие администраторы предпочитают создавать учетные записи пользователей для любых систем с минимальными привилегиями из соображений безопасности. Итак, вы можете спросить, как создать учетную запись пользователя для службы Amazon S3 с минимальными разрешениями на резервное копирование баз данных с помощью SQLBAckupAndFTP в указанную корзину и папку? Это очень просто.Просто подключитесь к Консоли AWS, создайте группу, укажите политику для группы и добавьте пользователя в группу. Позвольте мне подробно рассказать вам, как это сделать. Войдите в консоль AWS Чтобы войти в консоль AWS, откройте страницу https://console.aws.amazon.com/console/home, введите свой адрес электронной почты и пароль и войдите в систему. Если у вас нет пользователя Amazon.com учетной записи, выберите «Я новый пользователь». возможность создать его. Итак, вы должны увидеть панель навигации с пунктами меню вверху страницы. Ваше имя находится справа, щелкните свое имя, а затем выберите пункт меню «Учетные данные безопасности».Если вы получаете всплывающее окно с сообщением «Вы открываете страницу конфигурации для своих учетных данных root…», нажмите кнопку «Начать работу с пользователями IAM», чтобы управлять своими учетными данными. В левой части следующей страницы вы должны увидеть элементы: «Группы», «Пользователи», «Роли» и «Политика паролей». Сначала создадим группу с политикой безопасности. Создание группы с определенной политикой безопасности. Чтобы создать новую группу, выберите пункт «Группы» в левой части консоли AWS и нажмите кнопку «Создать новую группу».Вы увидите окно «Мастер создания новой группы», где вы можете ввести новое имя группы. Введите имя группы (пусть это будет SBFGroup) и нажмите кнопку «Продолжить», чтобы указать …

Учить больше

Как сделать резервную копию баз данных SQL Azure с помощью SQLBackupAndFTP

Размещено Алексеем 24 апреля 2013 г.

Как сделать резервную копию баз данных Azure SQL с помощью SQLBackupAndFTP Сделать резервную копию баз данных Azure SQL с помощью SQLBackupAndFTP с помощью Azure очень просто.Просто установите SQLBackupAndFTP с Azure, нажмите кнопку «Подключиться к SQL Server / Azure» и укажите свойства подключения для своих баз данных SQL Azure. Затем нажмите «Запустить сейчас» для резервного копирования баз данных SQL Azure. Требуются только две вещи. ваше внимание: вы должны знать свое имя сервера, чтобы указать соединение с базами данных SQL … Машине с вашим IP-адресом должен быть разрешен доступ к серверу … Строка подключения Azure SQL Если вы не знаете имя своего сервера базы данных SQL Azure, вы можете найти эта информация на сайте управления Windows Azure.Войдите в свою учетную запись Microsoft и щелкните элемент «БАЗЫ ДАННЫХ SQL», а затем щелкните свою базу данных на следующей странице. Затем щелкните «Показать строки подключения». Таким образом, вы увидите строки подключения для многих платформ. Просто скопируйте в буфер обмена значение свойства «Сервер» соединения «ADO.NET», как показано на скриншоте ниже: и вставьте его в поле «Имя сервера» в окне «Подключиться к SQL Server / Azure» приложения SQLBackupAndFTP: Разрешенные IP-адреса для SQLBackupAndFTP чтобы подключиться к базе данных SQL Azure, вам необходимо настроить брандмауэр Azure.В противном случае вы получите сообщение об ошибке: Невозможно открыть [сервер], запрошенный логином. Клиенту с IP-адресом [IP-адрес] запрещен доступ к серверу… Вы можете настроить брандмауэр Azure на сайте управления Windows Azure. Войдите в свою учетную запись Microsoft, щелкните элемент «БАЗЫ ДАННЫХ SQL» и щелкните свою базу данных на следующей странице: Затем щелкните ссылку «Управление разрешенными IP-адресами»: Итак, вы увидите страницу, на которой можно указать разрешенные ..

Учить больше

Лучшее программное обеспечение для резервного копирования SQL

Написал ruslan 28 февраля 2013 г.

Если у вас есть база данных SQL Server, вы должны сделать резервные копии.Позвольте мне рассказать вам о самом простом программном обеспечении для создания резервных копий SQL — это SQLBackupAndFTP. Загрузите бесплатную версию, настройку за 1 минуту, и ваши ежедневные резервные копии будут в безопасности в облаке. Что делает SQL Backup And FTP Вкратце, программное обеспечение создает резервные копии базы данных SQL Server (полные, Diff, Tran log) по любому расписанию. Сжимает и шифрует резервные копии. Отправляет резервные копии в локальную, сетевую папку, жесткий диск, FTP-сервер, Dropbox, Google. Драйв, Amazon S3, Box, SkyDrive. (Ранее мы писали о лучших местах для хранения резервных копий SQL Server). Отправляет подтверждение по электронной почте при успешном или неудачном выполнении задания. См. Полный список функций. SQLBackupAndFTP поставляется в бесплатной и платной версиях (от 29 долларов США) — см. Сравнение версий.Бесплатная версия полностью функциональна для неограниченного специального резервного копирования или для запланированного резервного копирования до двух баз данных — этого будет достаточно для многих мелких клиентов. Основная форма резервного копирования — это все, что вам нужно С самого начала меня поразило то, что сразу стало понятно, как работает программа, и я смог настроить задание резервного копирования из одной формы менее чем за минуту. Вот шаги, которые вы должны выполнить: Подключитесь к SQL-серверу и выберите базы данных для резервного копирования. Нажмите «Добавить место для резервного копирования», чтобы настроить, куда должны идти резервные копии (локальная, сетевая папка, жесткий диск, FTP-сервер, Dropbox, Google Drive, Amazon S3, Box, SkyDrive).Подробнее о лучших местах для хранения резервных копий SQL Server Введите свой адрес электронной почты, чтобы получать подтверждения по электронной почте об успехе или сбое задания. Установите время для начала ежедневного полного резервного копирования (или перейдите в Настройки, если вы …

Учить больше

Программное обеспечение для мониторинга сотрудников — лучшая стратегия

Написал ruslan 28.02.2013

Программное обеспечение для мониторинга сотрудников стало обычным явлением. Многие приложения делают снимки экрана монитора, фиксируют нажатия клавиш и движения мыши, отслеживают активные приложения и посещаемые сайты и, в крайних случаях, могут даже делать снимки с помощью веб-камеры.Было бы справедливо отслеживать, что делают ваши сотрудники, когда им платят за свое время. В конце концов, если они обменивают свое время на деньги, работодателю кажется справедливым знать, за что они платят. Итак, почему в некоторых случаях это все еще кажется морально неуместным? Вопрос далеко не теоретический. Если будет принято неправильное решение, компания может пострадать от судебных исков, столкнуться с негативной реакцией и общим падением производительности (противоположным тому, что планировалось) со стороны своих сотрудников или нанести ущерб имиджу компании.Давайте рассмотрим подробнее, какие методы мониторинга сотрудников можно считать действенными, а каких следует избегать. Бесшумный и прозрачный мониторинг сотрудников Бесшумный мониторинг сотрудников — это когда информация с компьютера сотрудника передается руководству компании без ведома пользователя. Прозрачный мониторинг сотрудников — это когда у сотрудника есть доступ ко всем данным мониторинга. Тихий мониторинг без согласия Тихий мониторинг без согласия — это простой случай, в котором легко отличить правильное от неправильного.Это происходит, когда программное обеспечение для мониторинга сотрудников используется без явного согласия сотрудника. Если за работником незаметно наблюдают и этот факт не прописан в его контракте с работодателем, он имеет полное юридическое и моральное право подать в суд на своего работодателя. Но, даже если упоминание об этом в контракте может сделать тихий мониторинг законным, делает ли …

Учить больше

SQL Server — лучшие места для хранения резервных копий

Написал ruslan 26 февраля 2013 г.

Все знают, что необходимо создавать резервные копии SQL Server — мы уже подробно освещали эту тему ранее (см. Лучшее программное обеспечение для резервного копирования SQL).Однако вопрос о том, где хранить резервные копии, часто остается без ответа. Я постараюсь сравнить некоторые из самых популярных вариантов этой задачи. В демонстрационных целях мы будем использовать параметры, которые предоставляет нам SQLBackupAndFTP, когда мы выбираем место назначения для хранения резервных копий. Резервное копирование SQL в локальную / сетевую папку / внешний жесткий диск Форма настроек папки SQLBackupAndFTP Если вы храните резервную копию на том же диске, что и ваша база данных, у вас не будет ее, когда диск выйдет из строя. Если вы сохраните его на том же сервере, вы можете потерять его, когда ваш сервер выйдет из строя.Если вы сохраните его в сети, вы можете потерять резервную копию, когда весь офис сгорит. Вы можете подумать, что вероятность этого невелика, но такие вещи случаются довольно часто, и умный администратор базы данных должен быть к этому готов. Так почему бы вам выбрать хранение резервных копий на месте, а не в облаке? Что ж, если ваша резервная копия данных превышает 100 ГБ, сетевое резервное копирование становится очень привлекательным вариантом. Поскольку скорость вашей сети всегда будет превышать скорость облака, это идеальный вариант для хранения больших резервных копий или менее важных резервных копий или дубликатов всего, что вы храните в облаке.А если вы выполняете резервное копирование на внешний жесткий диск, при наличии соответствующих политик вы можете перенести жесткий диск за пределы объекта. Однако я бы предпочел исключить из процесса человеческий фактор. Резервное копирование SQL на FTP-сервер SQLBackupAndFTP Форма настроек FTP Вы можете быть удивлены, но старый FTP работает …

Учить больше

Как сделать резервную копию базы данных SQL Azure на локальном компьютере

Несмотря на то, что База данных SQL Azure предоставляет встроенное резервное копирование, вы все равно можете создать локальную копию своей базы данных SQL Azure. Это может быть удобно, например, если вы хотите хранить резервную копию базы данных бесплатно дольше, чем разрешено встроенными инструментами Microsoft Azure, что обычно составляет от 7 до 35 дней, в зависимости от уровня обслуживания. Здесь мы подробно объясним, как сделать резервную копию базы данных SQL Azure на локальном компьютере.

Есть несколько способов загрузить базу данных Azure на свой компьютер.В таблице ниже приведены несколько ключевых методов с плюсами, минусами и сценариями использования. Щелкните имя для получения дополнительных сведений о каждом методе.

- Простой процесс
- Работает даже со старым SQL Server / SSMS
- Может экспортировать данные в файлы разных форматов
- Импортируются только данные, все остальные объекты будут потеряны
- Требуется SQL Server Management Studio
- Ручная процедура
Используйте, если вам нужно переместить данные из Azure в определенное место назначения (например,г. ваш старый SQL Server) или в определенном формате (например, плоский файл) с инструментами SQL Server Management Studio
- Может экспортировать данные в файлы разных форматов
- Может работать без присмотра / автоматически
- Импортируются только данные, все остальные объекты будут потеряны
Аналогичен мастеру импорта и экспорта SQL Server, но включает автоматический процесс.
- Создает наиболее точную копию базы данных
- Простой пользовательский интерфейс
- Требуется последняя установленная библиотека DAC
- Создает специальный файл BACPAC
- Ручная процедура
Используйте, когда вам нужно создать файл BACPAC с помощью инструментов SQL Server Management Studio
- Создает наиболее точную копию базы данных
- Может работать без присмотра / автоматически
- Требуется последняя установленная библиотека DAC
- Создает специальный файл BACPAC
Используйте, если вам нужно создать файл BACPAC из командной строки
- Может экспортировать данные в файлы разных форматов
- Может работать без присмотра / автоматически
- Импортируются только данные, все остальные объекты будут потеряны
- Импортирует только одну таблицу за раз
Используйте, если вам нужно сохранить данные из одной или нескольких таблиц в читаемом формате
- Простой пользовательский интерфейс
- Может создавать резервные копии по расписанию
- Не требует установленной библиотеки DAC
- Создает определенный файл BACPAC
Используется, когда необходимо регулярно выполнять автоматическое резервное копирование в файл BACPAC
- Все онлайн, установка ПО не требуется
- Создает специальный файл BACPAC
- Требуется учетная запись хранения Azure
Подходит, если у вас только браузер

Настройка брандмауэра базы данных SQL Azure

Поскольку мы собираемся подключаться к базе данных SQL Azure извне, нам необходимо настроить встроенный брандмауэр, добавив IP-адрес компьютера, на который мы хотим загрузить копию нашей базы данных.

Для этого перейдите на портал Azure, выберите «Базы данных SQL»> Ваша база данных> «Установить брандмауэр сервера»:

Установите брандмауэр в Azure

. Затем добавьте новое правило и не забудьте нажать «Сохранить». Для удобства вы можете нажать «Добавить IP-адрес клиента», и правило для текущего IP-адреса будет сгенерировано автоматически:

Добавить IP для Azure SQL

Как создать резервную копию базы данных SQL Azure с помощью мастера импорта и экспорта SQL Server

Используя встроенный SSMS SQL Server Import and Export Wizard, вы можете конвертировать данные между любыми источниками, включая ODBC, OLE DB, MS Access, MS Excel и даже простой файл.Это именно то, что мы будем использовать для копирования данных из базы данных SQL Azure на локальный компьютер.

Для начала откройте SQL Server Management Studio и подключитесь к своей базе данных SQL Azure. Если при подключении вы видите следующее сообщение:

Не удается открыть сервер «azure_server_name», запрошенный при входе в систему. Клиент с IP-адресом «83 .219.146.206» не имеет доступа к серверу. Чтобы включить доступ, используйте портал управления Windows Azure или запустите процедуру sp_set_firewall_rule в базе данных master, чтобы создать правило брандмауэра для этого IP-адреса или диапазона адресов.Это изменение вступит в силу в течение пяти минут.

, то вам нужно добавить свой IP-адрес в брандмауэр Azure.

После успешного подключения выберите нужную базу данных (в данном случае AdventureWorks), щелкните правой кнопкой мыши и выберите «Задачи»> «Импорт данных» (или «Экспорт данных»):

Мастер импорта данных SSMS

Это вызовет мастер импорта и экспорта SQL Server, в котором вам нужно выбрать «Поставщик данных .Net Framework для SqlServer» в качестве источника, а затем ввести сведения о вашей базе данных Azure:

Импорт свойств данных

Самый простой способ сделать это — ввести ConnectionString, который можно получить на портале Azure:

Получите соединение Azure SQL ADO

Не забудьте заменить {your_username} и {your_password} в строке подключения на реальные значения.

При нажатии кнопки «Далее» запускается проверка соединения. Если все пойдет хорошо, вас попросят указать параметры пункта назначения. Из раскрывающегося списка вы сможете выбрать не только SQL Server, но и Excel, Access и даже Flat File:

Поставщики SSMS select

Если вы хотите экспортировать данные в SQL Server, вы можете получить строку подключения, используя следующий запрос:

 выбрать
'источник данных =' + @@ имя_сервера +
'; исходный каталог =' + db_name () +
case type_desc
когда "WINDOWS_LOGIN"
затем '; trust_connection = true'
еще
'; идентификатор пользователя =' + suser_name ()
конец
из сис.server_principals
где name = suser_name ()

После успешного подключения к месту назначения вам будет предложено выбрать экспорт всех данных или только результата определенного запроса. Выбор всех данных потребует от вас выбора таблиц для экспорта. При выборе только данных запроса вам будет предложено ввести текст запроса.

Последний шаг запустит экспорт. Экран успешного экспорта будет выглядеть примерно так:

количество импортируемых строк

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

Как сделать резервную копию базы данных SQL Azure с помощью служб интеграции SQL Server (SSIS)

SQL Server Integration Services — мощная платформа, которая позволяет интегрировать и преобразовывать данные между различными приложениями. Мы уже сталкивались с этим в предыдущем разделе, когда экспортировали базу данных Azure с помощью мастера импорта и экспорта SQL Server.

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

Например, если вы сохранили параметры экспорта в AzureExport.dtsx, вы можете запустить его снова, используя следующую команду:

 DTEXEC.EXE / F "AzureExport.dtsx"

Если вы предпочитаете графический интерфейс, вы можете использовать приложение Execute Package Utility (DTEXECUI), хотя оно требует, чтобы на SQL Server были установлены инструменты управления — Basic или Business Intelligence Studio.

Как экспортировать базу данных SQL Azure в файл BACPAC

SQL Server Management Studio включает простой вариант экспорта базы данных Azure SQL в файл .bacpac. В этом руководстве мы покажем, как это сделать с помощью SSMS.

Требования

Вам понадобится установленная SSMS
Убедитесь, что правило брандмауэра включено в Azure SQL Server
База данных SQL Azure установлена 
Подключение к Интернету

Сначала необходимо подключиться к базе данных SQL Azure с помощью SSMS.

После того, как вы войдете в SSMS, щелкните правой кнопкой мыши свою базу данных SQL Azure и выберите «Задача» и «Экспорт приложения уровня данных»:

Экспорт SSMS в bacpac

При выборе этого параметра откроется мастер. В первой части будет показано введение. Во введении нажмите Далее.

В разделе Export Settings перейдите к Save to local disk и укажите локальный путь на вашем компьютере для установки файла BACPAC.

Путь для экспорта Azure DB

Мастер перейдет в раздел «Сводка», чтобы показать все настроенные параметры.Нажмите «Далее» в этом разделе.

В конце концов, если все в порядке, отобразится зеленый статус. Процесс экспорта включает в себя экспорт данных, схем, таблиц, ссылок и всех других компонентов базы данных. Как только вы получите сообщение, вы можете проверить bacpac файла, экспортированного и использованного для восстановления базы данных на другой SQL Server.

Как сделать резервную копию базы данных SQL Azure с помощью утилиты SqlPackage

Утилита SqPackage позволяет импортировать или экспортировать данные с помощью командной строки.Это может быть очень полезно, если нам нужно автоматизировать и программировать задачи импорта и экспорта. Это программное обеспечение обычно устанавливается вместе с SSMS или SSDT. Чтобы найти его, вы можете использовать в cmd следующие команды (сначала обязательно запустите cd \):

 каталог sqlpackage.exe / s / p

Команда покажет путь к утилите sqlpackage. Путь обычно похож на этот:

 Диск: \ Архивы программ \ Microsoft sql server \ 130 \ DAC \ bin

Синтаксис SqlPackage для экспорта следующий:

 sqlpackage.exe / Action: Export /ssn:tcp:.database.windows.net,1433 / sdn:  / su:  / sp:  / tf:  / p: Storage = Файл

Давайте запустим простой пример:

 sqlpackage.exe / Действие: Экспорт /ssn:tcp:sqlftpbackupserver.database.windows.net / sdn: sqlftpbackupdb / su: daniel /tf:c:\sql\sqlftpbackup.bacpac / sp: yourpwd / p: Storage = File

Мы экспортируем файл ( Export ) на сервер SQL Azure с именем sqlftpbackupserver.database.windows.net , а имя исходной базы данных — sqlftpbackup. Исходный пользователь — Дэниел, а целевой файл, в который мы будем экспортировать, находится в c: \ sql \ sqlftpbackup.bacpac sp предназначен для указания пароля базы данных Azure SQL пользователя Azure SQL. Наконец, сохраним в файле файл .

Общие ошибки

Типичная ошибка:

*** Ошибка экспорта базы данных: не удалось подключиться к серверу базы данных.
Невозможно открыть сервер sqlftpbackupserver, запрошенный при входе в систему.Клиенту с IP-адресом «181.114.103.171» не разрешен доступ к серверу. Чтобы включить доступ, используйте портал управления Windows Azure или запустите процедуру sp_set_firewall_rule в базе данных master, чтобы создать правило брандмауэра для этого IP-адреса или диапазона адресов. Это изменение вступит в силу в течение пяти минут.

Если это ваша ошибка, установите брандмауэр. О том, как это сделать, мы уже писали в начале статьи.

Еще одна типичная ошибка:

*** Ошибка экспорта базы данных: уровень совместимости базы данных ’12’ не находится в поддерживаемом диапазоне от 80 до 130.

Это проблема с Azure. Уровень в SQL Server в локальной среде составляет от 80 до 130, однако в Azure SQL уровень hte равен 12. Для этого нам необходимо запустить следующий T-SQL в Azure. Вы можете использовать SSMS, но я предпочитаю использовать редактор запросов на портале, потому что вам не нужно ничего устанавливать:

 ИЗМЕНИТЬ БАЗУ ДАННЫХ sqlftpbackupdb УСТАНОВИТЬ COMPATIBILITY_LEVEL = 130;

изменить базу данных в Azure

Как создать резервную копию базы данных SQL Azure с помощью утилиты BCP

В этом примере у нас будет таблица с именем xxx, и мы хотим экспортировать ее в файл с помощью утилиты bcp (программа массового копирования).В командной строке проверьте, есть ли у вас утилита BCP. Если у вас его нет, вы получите следующее сообщение:

bcp не распознается как внешняя / внутренняя команда, работающая программа или командный файл

Если вы получили это сообщение, вы можете скачать утилиту bcp здесь. После установки напишите в командной строке:

 bcp sqlftpbackupdb.SalesLT.CustomerAddress out c: \ sqlfile \ cust.dat -c -U daniel -S tcp: sqlftpbackupserver.database.windows.нетто

Sqlftpbackupdb — это имя базы данных. SalesLT — это схема, а CustomerAddress — это таблица для экспорта. Мы экспортируем таблицу в локальный файл на диске c: в папке sqlfile, и имя файла будет cust.dat. -c используется для преобразования в тип данных char. -U используется для указания имени пользователя и -S имени сервера Azure.

Имя входа в Azure SQL и имя сервера

В командной строке будет запрошен пароль. Напишите пароль.

Типичное сообщение об ошибке:

SQLState = 37000, NativeError = 40615

Ошибка = [Microsoft] [Драйвер ODBC 13 для SQL Server] [SQL Server] Не удается открыть сервер sqlftpbackupserver, запрошенный при входе в систему.Клиент с IP-адресом «181.114.102.51» не имеет доступа к серверу. Чтобы включить доступ, используйте портал управления Windows Azure или запустите процедуру sp_set_firewall_rule в базе данных master, чтобы создать правило брандмауэра для этого IP-адреса или диапазона адресов. Это изменение вступит в силу в течение пяти минут.

Чтобы устранить эту ошибку, перейдите на портал Azure и перейдите в раздел Брандмауэр / Виртуальные сети:

Параметр брандмауэра в Azure

В брандмауэре / виртуальных сетях нажмите + Добавить IP-адрес клиента и нажмите Сохранить:

Добавить IP-адрес клиента

Если все в порядке, вы сможете скопировать файлы, и он покажет количество скопированных строк:

Данные импорта BCP

Некоторые советы:

Если есть миллионы строк, вам нужно будет указать размер пакета.Вы можете использовать -b, чтобы указать количество строк в пакете.
Убедитесь, что учетная запись в командной строке имеет доступ для записи данных в указанную локальную папку.
Также важно подключение к Интернету. Если у вас нет хорошего подключения к Интернету, операция bcp может завершиться ошибкой.
Для повышения производительности может быть полезна подсказка TABLOCK (-h tablock). Эта подсказка блокирует таблицу во время операций bcp для повышения производительности bcp.
По умолчанию в этих операциях триггеры не срабатывают.

Как сделать резервную копию базы данных SQL Azure с помощью SqlBackupAndFtp

SqlBackupAndFtp — чрезвычайно мощный инструмент для резервного копирования баз данных SQL в Azure, Dropbox, FTP в локальный файл, Amazon S3, Box, Google Drive и другие варианты. В этом примере мы создадим резервную копию базы данных Azure SQL в локальном файле с именем sqlftpbackupdb201803082133.zip.

Сначала необходимо загрузить и установить SqlBackupAndFtp. Приложение спросит тип сервера. В этом примере это База данных SQL Azure. Он запросит имя Azure SQL Server, имя пользователя и пароль. Эта информация устанавливается при создании Azure SQL Server.

Учетные данные Azure

Следующим шагом будет выбор базы данных. В этом примере имя базы данных SQL Azure — sqlftpbackupdb. Нажмите . Выберите базы данных и проверьте базу данных. Вы также можете увидеть системные базы данных (основная база данных в Azure SQL):

Выбрать базу данных

В разделе «Хранить резервные копии» выберите место назначения, вы можете хранить в локальной папке, сетевой папке, NAS, FTP-сервере, Amazon S3, Dropbox, Google Drive, Onedrive, Box и многих других вариантах.В этом примере мы будем хранить резервную копию в локальном хранилище.

Где хранить данные

Последним шагом будет Запуск задания. Вы можете «Запустить немедленно» с опцией «Запустить сейчас» или можете запланировать резервное копирование. Вы также можете получать электронные письма, если резервное копирование прошло успешно или не удалось. Это чрезвычайно полезно, если процесс резервного копирования занимает много времени, потому что вам не нужно ждать его завершения, так как вы получите уведомление в случае успеха или неудачи. Для отправки этих писем не нужно устанавливать SMTP-сервер или что-то еще.

Выберите Azure DB

. Если все пойдет нормально, будет создан zip-файл с резервной копией.

Как экспортировать базу данных SQL Azure с портала Azure

Вы можете сохранить базу данных SQL Azure в файле BACPAC , который по сути является файлом ZIP, содержащим метаданные и данные из него. Вы можете загрузить файл BACPAC локально, а затем импортировать его обратно в Azure или в локальную установку SQL Server. Однако имейте в виду, что для обеспечения согласованности транзакций копия вашей базы данных Azure будет создана в процессе экспорта.Эта копия рассматривается как вторая база данных и учитывается как таковая. Таким образом, если ваша база данных довольно большая, для ее локального экспорта может потребоваться значительное время и деньги.

Давайте сначала создадим учетную запись хранения Azure. Учетная запись хранения — это место в облаке, где вы можете хранить файлы, большие двоичные объекты, очереди. Это избыточно и безопасно. Чтобы создать его, войдите на портал Azure, перейдите к поиску и напишите Хранилище и перейдите в Учетные записи хранилища (классический). Обратите внимание, что вы можете создать bacpac только в классических учетных записях хранения:

Создание классической учетной записи хранения

Пришло время экспортировать резервную копию базы данных в только что созданную учетную запись хранилища Azure.Выберите свою базу данных Azure, а затем выберите экспорт:

Параметр экспорта базы данных Azure

Укажите имя файла и убедитесь, что подписка в порядке. Настройте логин и пароль. В разделе «Настроить обязательные параметры» нажмите кнопку, чтобы настроить его:

Экспорт в свойства bacpac

Выберите классическую учетную запись хранилища Azure, созданную ранее, и нажмите + , чтобы создать новый контейнер. Укажите имя для контейнера и сохраните файл BACPAC в этом контейнере:

Создать контейнер в учетной записи хранения Azure

Если вам нужно проверить бакпак, щелкните только что созданный контейнер:

Проверьте контейнер

В контейнере вы сможете увидеть файл.Щелкните правой кнопкой мыши и нажмите Загрузите , чтобы иметь на локальном компьютере:

Скачать bacpac для учетной записи хранения Azure

Ссылки

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-export

Azure SQL Database: Built-in Backups vs Import/Export

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Бэкап sql базы: Резервное копирование и восстановление базы данных в MS SQL Server

Как сделать бэкап локальной базы данных MSSQL

Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server / Хабр

Могу ли я развернуть бэкап на версии SQL Server, отличной от той, на которой был сделан бэкап? Какие проблемы могут возникнуть?

Могу ли я использовать операцию восстановления для создания копии базы даных? Что может пойти не так?

Можно ли присоединять как базу данных файл MDF, если у меня нет файла журнала транзакций?

Моя БД лежит на SAN. Я слышал, что бэкапов SAN достаточно. Это правда?

Почему я не могу использовать в качестве бэкапов копии файлов данных, созданных Windows? Мне не нужна возможность восстановления на произвольный момент времени.

У меня очень маленькая БД. Почему я не могу просто «выгрузить» каждую таблицу на диск для создания резервной копии?

Зачем платить деньги за утилиты, делающие бэкапы, если SQL Server сам умеет это делать?

Если бэкап лежит на сетевой шаре, может ли кто-то прочитать его?

А кто-нибудь может изменить содержимое резервной копии?

Существует ли какой-либо флаг, установив который при создании бэкапа, я могу быть уверен, что всегда смогу из него восстановиться?

Не содержит ли бэкап что-нибудь кроме данных? Может ли кто-нибудь прочесть пароли из него?

Зачем в бэкапе индексы, статистика и остальные штуки, которые легко пересоздать? Это же просто потеря времени?

ОМГ! Я только что удалил таблицу! Я знаю, что это есть в журнале транзакций. Как мне её вернуть?

А если я просто хочу создать с помощью бэкапа скрипт для построения БД, без восстановления непосредственно бэкапа…?

Создание и восстановление резервной копии базы данных в Microsoft SQL Server 2008 R2

0. Оглавление

1. Создание резервной копии

2. Восстановление базы данных из резервной копии

3. Восстановление резервной копии в другую базу данных (копирование данных)

Смотрите также:

Техподдержка: Настройка регулярного резервного копирования БД MS SQL Server

С помощью «Планировщика Windows» (для бесплатной версии)

С помощью «SQL Server Agent» (в бесплатную версию не входит)

SQL Server 2008: бэкапим с умом. Часть 1: Теория / Хабр

Первые шаги

Full Backup

Log backup

Differential Backup

Вместо постскриптума

Разбираемся с утилитами для бэкапа баз данных — «Хакер»

Содержание статьи

Виды бэкапов баз данных

Barman

Sypex Dumper

SQL Backup And FTP

Особенности бэкапа MS SQL Server

Iperius

Handy Backup

Создание резервной копии базы данных в MS SQL Server 2012

0. Оглавление

1. Создание резервной копии базы данных

2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Смотрите также:

MS SQL SERVER EXPRESS

Запланированное автоматическое резервное копирование базы данных SQL с использованием SSMS

SQL Backup Бесплатно | Бесплатная резервная копия MS SQL Server

Резервное копирование баз данных SQL в облака SkyDrive или Box с помощью SQLBackupAndFTP

Как написать политику доступа к Amazon S3 с минимальным разрешением, необходимым для резервного копирования баз данных с помощью SQLBackupAndFTP

Как сделать резервную копию баз данных SQL Azure с помощью SQLBackupAndFTP

Лучшее программное обеспечение для резервного копирования SQL

Программное обеспечение для мониторинга сотрудников — лучшая стратегия

SQL Server — лучшие места для хранения резервных копий

Как сделать резервную копию базы данных SQL Azure на локальном компьютере

Настройка брандмауэра базы данных SQL Azure

Как создать резервную копию базы данных SQL Azure с помощью мастера импорта и экспорта SQL Server

Как сделать резервную копию базы данных SQL Azure с помощью служб интеграции SQL Server (SSIS)

Как экспортировать базу данных SQL Azure в файл BACPAC

Требования

Как сделать резервную копию базы данных SQL Azure с помощью утилиты SqlPackage

Общие ошибки

Как создать резервную копию базы данных SQL Azure с помощью утилиты BCP

Как сделать резервную копию базы данных SQL Azure с помощью SqlBackupAndFtp

Как экспортировать базу данных SQL Azure с портала Azure

Ссылки

Добавить комментарий Отменить ответ