Разбираемся с утилитами для бэкапа баз данных. Sql бэкап


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

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

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

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

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

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

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

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.

habr.com

Правильный Бэкап Microsoft SQL Server

Такую схему резервного копирования использую я. Восстановить БД можно вплоть до 15 минут. (Работа частично связана с аутсорсингом, есть подопечные, которые выполняют задания, поэтому так расписываю, можно сказать что взято из руководства для инженеров):

  1. Используется полная (FULL) модель восстановления базы данных, проверить можно в свойствах конкретной базы.
  2. При настройке Резервного копирования все бекапы делаются в одну папку, на сетевое хранилище, для каждой бд SQL должен создавать отдельный каталог (ниже все показано в картинках).
  3. Предприятие уведомить о проверке хранилища (после перепадов напряжения\выключения света).

Должно быть создано 4 задания, которые должны называться так:

  •  «01 FULL» - полный бекап.
  • «02 DIFF» - Разностный (дифференциальный).
  • «03 TRANZ» - транзакции
  • «04  CLEAN» - чистка (где должно быть 2 задания для расширений bak и trn)
  • Обязательно сохраняем все задания нажав на дискету.
  • Запускаем каждое задание по очереди проверяем выполнение.

 Заходим в свойства базы, проверяем что используется полная модель восстановления (Recovery model: FULL), если  стоит простая (Simple), то переводим базу в FULL.

Бэкап полный (01 FULL). Примечание: делаются все базы, 1 раз в неделю с субботы на воскресенье ночью. Для каждой базы создается своя директория  (автоматом), под цифрой 3 на левом скриншоте.

 

  «02 DIFF» Бекап разностный (дифференциальный). Примечание: делается раз в день. База только RFTS-ALCO.

 

 

«03 TRANZ» Бекап транзакций. Примечание: делается каждый день, каждые 15 минут, база только RFTS-ALCO.  Расширение файла trn.

  

«04  CLEAN» Чистка системы. Примечание: создается один MaintancePlan в котором содержится ДВА задания:

  1. Первое чистит устаревшие BAK файлы.
  1. Второе чистит устаревшие TRN файлы.

 

 

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

lite-blog.ru

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

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

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

 

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

Для начала разберемся с тем, какие вообще бывают бэкапы. Сервер баз данных не является обычным десктопным приложением, и, чтобы обеспечить выполнение всех свойств 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. Сам процесс развертывания несложен для любого админа.

 

xakep.ru

Backup SQL

А также: бэкап SQL, бэкап 1С.

Серверная 1С содержит данные в базе данных, которая находится на SQL сервере. Сегодня мы рассматриваем вариант MS SQL 2005/2008.

Чтобы данные не были потеряны в случае сгоревшего диска сервера или других форс-мажорных ситуаций – необходимо с самого начала делать бэкапы (backup).

Делать ручками каждый день Backup SQL базы 1С конечно никто не хочет. Для этого есть автоматические средства. Познакомимся с ними.

 

Настройка Backup SQL

Настройка Backup SQL для базы 1С ничем не отличается от настройки бэкапа для любой другой базы данных.

Для настройки запустите MS SQL Management Studio. Эта программа находится в группе программ MS SQL.

 

Добавление задания бэкапа SQL базы 1С

Задания автоматического бэкапа баз SQL находятся в ветке Management / Maintenance plans.

 

Чтобы добавить новое задание бэкапа щелкните на группу Maintenance plans правой кнопкой мыши и выберите New Maintenance Plan.

 

Введите название задания. Название имеет значение только для Вас. На всякий случай лучше использовать английские символы.

 

Настройка задания бэкапа SQL базы 1С

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

Список вариантов операций выведен слева внизу. Выберите Back Up Database Task двойной кнопкой мыши или просто перетащите вправо.

 

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

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

 

В окне настройки выберите нужные базы SQL 1С (можно сразу несколько или по одной).

 

Выберите место сохранения бэкапа базы SQL 1С. Необходимо выбрать физически другой винчестер. Организационно можно поставить галочку «Создать подпапки».

 

Теперь настроим расписание backup. Расписание backup по-умолчанию добавилось само. Но Вы можете добавить несколько расписаний (например, одно – ежедневное, одно – еженедельное и т.п.). Нажмите кнопку настройки расписания backup.

 

На скриншоте пример ежедневного Backup SQL базы 1С в 3 ночи.

 

Чтобы расписание backup в списке было красиво-понятным, его можно изменить.

 

Сохранение задания бэкапа SQL базы 1С

Нажмите записать. Задание появится слева в списке.

Это важно! Проверьте правильность создания задания Backup SQL базы. Для этого нажмите на задании правой кнопкой и выберите Execute.

В результате должен появится файл бэкапа по указанному пути. Если что-то не так – удалите задание (Del) и начните с начала.

howknow1c.ru

Запросы MS SQL на бэкап и восстановление и создание моментальных снимков базы данных - «Ask SQL»

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

Резервное копирование, восстановление и создание моментальных снимков базы данных на сервере MS SQL

MS SQL backup and resotore database or creating snapshots

 

-- MS SQL - запрос создания устройства резервного копирования: EXEC master.dbo.sp_addumpdevice @devtype = N'disk', @logicalname = N'NameDeviceBackup', @physicalname = N'R:\Backup\NameDeviceBackup.bak' GO -- MS SQL - запрос создания моментальных снимков баз данных: USE [master] GO CREATE DATABASE [DbName_2012_01_19] ON ( NAME = N'DbName_dat', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\DbName_2011_01_17.ss' ) AS SNAPSHOT OF [DbName] GO -- сделать бэкап: BACKUP DATABASE DbNameSuperName TO DISK='C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\DbNameSuperName.bak' with FORMAT -- восстановить из бэкапа: -- определяем ключи, то есть имена файлов mdf и ldf  restore filelistonly from disk='C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\ArchiveDB.bak' -- подставляем их в запрос и выполняем восстановление restore database ArchiveDbName_2013 from disk='C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\ArchiveDB.bak' with move 'DbName_dat' to 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\ArchiveDbName_2013.mdf', move 'DbName_log' to 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\ArchiveDbName_2013.ldf'

 

Если нет файла .ldf то необходимо следующее

  1. Создаем новую базу с таким же именем и такимиже по именам и расположению .mdf и .ldf файлами 
  2. Останавливаем сервер, подменяем файл .mdf 
  3. Стартуем сервер, не обращаем внимания на статус базы 
  4. Выполняем скрипт:

 

Use master go sp_configure 'allow updates', 1 reconfigure with override go -- 4. Там же выполняем select status from sysdatabases where name = '<db_name>' и запоминаем/записываем значение на случай неудачи ребилда лога -- 5.Там же выполняем update sysdatabases set status= 32768 where name = '<db_name>' -- 6. Перезапускаем SQL Server 7. В принципе база должна быть видна (в emergency mode). Можно, например, заскриптовать все объекты -- 8. Из QA выполняем DBCC REBUILD_LOG('<db_name>', '<имя нового лога с указанием полного пути>') SQL Server скажет - Warning: The log for database '<db_name>' has been rebuilt. -- 9. Если все нормально, то там же выполняем Use master go sp_dboption '<db_name>', 'single user', 'true' go USE <db_name> GO DBCC CHECKDB('<db_name>', REPAIR_ALLOW_DATA_LOSS) go -- 9.1. Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode sp_dboption '<db_name>', 'dbo use only', 'true' -- 10. Если все в порядке, то sp_dboption '<db_name>', 'single user', 'false' go Use master go sp_configure 'allow updates', 0 go

 

 

 

По сути механизм копирования баз данных из SSMS выглядит таким образом

 

1. Отсоединить базу данных (правой кнопкой мыши кликнуть на базу и выбрать Detach, убедитесь что нет подключенных пользователей)2. Копируйте mdf и ldf файлы в Ваше новое место хранения3. Присоединить базу данных (правой кнопкой мыши кликнуть на базу и выбрать Attach)

 

По сути происхдит следующее:

USE MASTER; GO ALTER DATABASE TestDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE; GO -- Detach DB EXEC MASTER.dbo.sp_detach_db @dbname = N'TestDB' GO

 

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

 

-- перемещаем файл базы из Loc1 в Loc 2 -- И ретачим базу (Re-Attached) CREATE DATABASE [TestDB] ON ( FILENAME = N'F:\loc2\TestDB.mdf' ), ( FILENAME = N'F:\loc2\TestDB_log.ldf' ) FOR ATTACH GO

 

Дата публикации: 2015-05-16 12:28:49 MS SQL

0

Отзывы:

asksql.org

Записная книжка сисадмина, шпаргалка - Записная книжка сисадмина

Викиадмин, записная книжка сисадмина, она же шпаргалка: нашел нужное решение - используй это. У меня получилось же. :)

Мне записная книжка системного администратора служит для того, чтобы в нужный момент не изучать материал заново, а просто сделать то, что нужно, используя проверенное решение и экономя время. Это может быть что угодно: настроить Apache, установить MySQL, подкорректировать что-то в Linux, подкинуть правило в iptables, настроить музыкальный сервис в офисе с помощью MPD или просто поставить CRM для отдела продаж. Конечно, жизнь не стоит на месте и какие-то “рецепты” могут быть уже устаревшими (как было с SAMBA и user, если кто в курсе). Поэтому, если будет желание указать на ошибку или предложить другое решение - почта чуть ниже на этой же странице. Зачем это мне: просто небольшая дань уважения тем, кто придумал описанное тут программное обеспечение и, зачастую, дал его миру совершенно бесплатно.

Основные направления сайта

На данных страницах описание и настройки сервисов в основном под Linux, а если ещё точнее, то чаще всего CentOS. Эта система меня чаще всего “кормит”, поэтому и решений больше. (Даже сейчас пишу с ноутбука под усправлением CentOS. С Gnome3 получается потрясающая комбинация.) Есть и ноут с Arch, и, согласитесь, их вики просто потрясающе наполнена. :)

Вопросы об этом сайте

  • В записную книжку сисадмина принимаются новые статьи об информационных технологиях (apache, nginx, crm, web-движки и так далее). Информацию и предложения присылайте на почту.

  • Если страница оказалась полезной, отправьте её в твиттер или любой другой сайт. Вам будет проще повторно её найти и мне спасибо за размещение информации.

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

  • На этом сервере работает iperf3 в режиме сервиса. Если вам нужно произвести замер скорости, наберите команду iperf3 -c wikiadmin.net и получайте результат. Cервер находится в Москве, стоит учесть при замере из другого региона.

  • Если на сайте стоит добавить какую-либо информацию по установке и настройке чего-либо, напишите. Максимальное количество предложений опишем в первую очередь.

  • У сайта принципиально нет https-версии. Настроить в cron LE не сложно и без проблем можно перейти на https. Но зачем? Я могу понять сайты, где необходимо вводить данные карты, пользователя и т.д., но https для read-only сайта - это бред. К тому же я доволен скоростью этого ресурса и не хочу его увеличивать ни на секунду! :)

  • Есть дополнительное хранилище для CentOS 7 x64. Вот ссылка на repo-файл. Если вы увидели что-то, что есть в Fedora, но нет в CentOS - напишите, соберём и выложим. Найти меня можно в spotchat на каналах #centos-ru и #linuxmint-ru.

Dec 12th, 2015 8:02 am

wikiadmin.net

1С, MySQL, MS SQL, PostgreSQL, Oracle

Резервная копия базы данных – краеугольный камень информационной безопасности любого проекта. Для бэкапа базы данных любого типа Handy Backup предоставляет универсальный и специализированные инструменты, эффективно сохраняющие резервные копии БД.

Handy Backup™ - профессиональное программное обеспечение, позволяющее производить резервное копирование и восстановление баз данных в автоматическом режиме. Помимо бэкапа БД, Handy Backup позволяет сохранять резервные копии данных любого другого типа.

Храните и восстанавливайте данные 1С файловой и SQL-версий, начиная с 1С 7.7 и кончая самыми современными решениями 1С 8.х с помощью инструмента 1С, входящего в Handy Backup!

Инструмент Oracle основан на внутренней утилите RMAN и предоставляет полную совместимость с Oracle. Позволяет использовать все “родные” функции бэкапа и восстановления Oracle.

Создаёт резервные копии баз данных и таблиц MySQL, формируя набор инструкций SQL, способный восстановить данные при выполнении. Поддерживает все механизмы памяти.

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

Handy Backup использует специальный инструмент для бэкапа баз данных, таблиц и схем PostgreSQL, позволяющий получать доступ к локальным и сетевым данным PostgreSQL.

Инструмент MariaDB позволяет создать последовательность SQL-операторов, которые восстанавливают состояние скопированных таблиц. Как и MySQL, поддерживает разные механизмы хранения.

Плагин для работы с СУБД Lotus Notes/Domino позволяет осуществлять резервное копирование баз данных, таблиц и файлов Lotus Notes, восстанавливать и клонировать ранее сохранённые данные.

Handy Backup имеет плагин для работы с базами данных IBM DB2, обеспечивающий горячее и холодное резервное копирование баз данных DB2 и их восстановление через интерфейс API СУБД.

Создание резервной копии базы данных с помощью ODBC возможно в любой СУБД, для которой в системе установлен соответствующий драйвер. Для этой операции используется универсальный инструмент “Database”, способный работать как с SQL, так и с не-SQL ориентированными СУБД:

Рекомендуемое решение для резервного копирования баз данных

Версия 7.17.0 от 14 сентября 2018. 164 MBПрограмма резервного копирования Handy Backup. 7400 RUB за лицензию

Получите доступ ко всем инструментам резервного копирования и восстановления баз данных, приобретя решение Office Expert! Пробный перод - 30 дней.

Существуют два различных метода резервного копирования баз данных под управлением любой современной СУБД:

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

    Например, для архитектуры серверов СУБД Master-to-Slave, вы можете выключить сервер Slave, переписать все файлы и перезапустить сервер.

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

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

Репликация

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

Сбой одного из серверов не отражается на работоспособности системы и безопасности данных, и в любой момент оператор может поменять местами подчинённый (Slave) и главный (Master) серверы для обеспечения стабильной работы.

На заметку: Хотя репликация повышает стабильность работы БД, регулярный бэкап она не заменит. Если ваша Master-база случайно испортится, опасные изменения автоматически отразятся и на Slave-базах.

Кластерирование

Вышеописанный принцип верен и для кластерирования, размножения одной базы данных по нескольким серверам (SQL-узлам) без выделения специальной роли каждому серверу. Кластеры обычно основаны на распределённых механизмах хранения данных.

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

Информация о лицензиях

Существуют два решения Handy Backup, ориентированные прежде всего на коммерческого пользователя. Оба этих решения снабжаются “из коробки” полным комплектом инструментов для работы с базами данных различных типов:

Резервное копирование и восстановление баз данных с помощью версий Office Expert или Server Network. Пробный период - 30 дней!

  • Если у вас только один сервер СУБД, попробуйте решение Handy Backup Office Expert.
  • Если вам необходимо обслуживание нескольких серверов и рабочих станций с СУБД в локальной сети, выберите решение Handy Backup Server Network

Вы можете найти информацию о ценах и лицензиях на странице покупок продуктов.

Это видео продемонстрирует вам методы резервного копирования и восстановления баз данных в Handy Backup на примере работы с СУБД и инструментом MySQL Backup.

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

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

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

Читайте также:

Cnet Editor’s Rating:

Outstanding

www.handybackup.ru