Резервное копирование базы данных: Путеводитель по резервному копированию баз данных / Хабр

Содержание

Вводная информация о резервном копировании баз данных Oracle

Бла, бла, бла. Всегда нужно делать бекапы, иначе будет как на картинке “Он дропнул базу и не делал бэкапы”.

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

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

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

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

ora, listener.ora и tnsnames.ora

Резервное копирование выполняеся:

  • Средствами операционной системы.
  • Средствами RMAN (Recovery Manager).

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

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

Режимы ARCHIVELOG и NOARCHIVELOG

Oracle записывает все изменения, которые вносятся в находящиеся в памяти блоки данных, в оперативные журналы повторного выполнения (online redo logs), и делает это, как правило, перед их записью в файлы базы данных. Во время процесса восстановления Oracle использует зафиксированные в файлах этих журналов изменения для приведения базы данных в актуальное состояние.

Oracle поддерживает два режима для управления такими файлами.

  • Режим архивирования журналов (ARCHIVELOG). В этом режиме Oracle сохраняет (архивирует) заполненные журналы повторного выполнения. Следовательно, на сколько давно бы не выполнялось резервное копирование, если используется режим ARCHIVELOG, базу данных всегда можно будет восстановить до любой точки во времени с помощью архивных журналов.
  • Режим без архивирования журналов (NOARCHIVELOG). В этом режиме заполненные журналы повторного выполнения перезаписываются, а не сохраняются. Это, следовательно, означает, что в случае использования режима NOARCHIVELOG выполнять восстановление можно будет только из резервной копии и что все остальные изменения, которые были внесены в базу данных после выполнения резервного копирования, будут утрачиваться. Этот режим обеспечивает возможность выполнения восстановления только после отказа экземляра базы данных. В случае возникновения неполадок с носителем (например, потеря диска), функционирующую в режиме NOARCHIVELOG базу данных можно будет восстановить только из резервной копии и, естественно, с потерей всех изменений, которые были внесены в нее после создания этой резервной копии.

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

Резервное копирование всей или части базы данных

Подвергать резервному копированию можно как всю базу данных так и только ее часть, вроде входящего в ее состав табличного пространства или файла данных. Обратите внимание, что в случае, когда база данных функционирует в режиме NOARCHIVELOG, осуществлять резервное копирование лишь части базы данных, также называемое частичным резервным копированием (partial database backup), нельзя, если только все те табличные пространства и файлы, которые подлежат резервному копированию, не явлются доступными только для чтения. Выполнять резервное копирование всей базы данных, также называемое полным резервным копированием (whole database backup), можно как в режиме ARCHIVELOG, так и в режиме NOARCHIVELOG.

Чаще всего выполняется полное резервное копирование. Оно предполагает копирование не только всех файлов данных, но и еще одного важного файла – управляющего. Без управляющего файла Oracle не будет открывать базу данных, поэтому для восстановления помимо резервных копий всех файлов данных, необходимо также обязательно обладать и новейшей резервной копией управляющего файла.

Согласованное (consistent) и несогласованное (inconsistent) резервное копирование

Согласованное резервное копирование (consistent backup) приводит к созданию согласованных резервных копий и не требует проводить процесс восстановления. При применении резервной копии для восстановления базы данных или ее части (например, табличного пространства или файла данных), сначала обычно требуется проветси восстановление данных из резервной копии (т.е. процедуру RESOTRE), а затем – восстановление работоспособности базы данных (т.е. процедуру RECOVER). В случае согласованного резервного копирования ни один из этих восстановительных шагов выполнять не требуется. В случае несогласованного резервного копирования (inconsistent backup) выполнение этих восстановительных шагов всегда является обязательным.

Oracle присваивает каждой транзакции уникальный системный номер изменения (System Change Number — SCN). Каждая фиксация, к примеру, будет проводить к увеличению этого номера. Всякий раз, когда Oracle устанавливает контрольную точку, все изменившиеся данные в оперативных файла данных записываются на диск. И всякий раз, когда это происходит. Oracle выполняет обновление контрольной точки потока (thread checkpoint) в управляющем файле. Во время этого обновления Orale делает так, чтобы все доступные для чтения и записи файлы данных и управляющие файлы согласовались с одним и тем же SCN-номером. База данных считается согласованной тогда, когда SCN-номера, хранимые в заголовках всех файлов данных, являются идентичными и совпадают с информацией о заголовках файлов данных, которая содержится в управляющих файлах. Главное запомнить, что один и тот же SCN-номер должен обязательно присутствовать во всех файлах данных и управляющем файле (или файлах). Пристутствие идентичного SCN- номера, означает, что в файлах данных содержатся данные за один и тот же промежуток времени. Если данные являются согласованными, никакие шаги по восстановлению после возврата (или копирования) набора фалов резервных копий на прежнее место не понадобятся.

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

При выполнении несогласованного резервного копирования получается, что в файлах резервной копии содержатся данные за разные промежутки времени. Дело в том, что работу большинства производственных систем не допускается прерывать для проведения согласованного резервного копирования. Вместо этого необходимо, чтобы эти базы данных работали 24 часа в сутки 7 дней в неделю. Это, следоватлеьно, означает, что резервное копирование этих баз данных должно выполняться в оперативном режиме, т.е. пока они остаются открытыми для транзакций. Изменение файлов данных пользователями во время проведения резервного копирования как раз и приводит к получению несогласованных резервных копий. Выполнение несогласованного резервного копирования не означает получения каких-то неправильных резервных копий. Однако во время восстановления одного только возврата таких резервных копий на прежнее место недостаточно. Помимо возврата их на прежнее место требуется также обязательно применить все архивные и оперативные журналы повторного выполенния, которые были созданы в промежутке с момента выполнения резервного копирования и до момента, до которого необходимо восстановить базу данных. Oracle будет считывать эти файлы и автоматически применять к файлам этих резервнх копий все необходимые изменения.

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

Резервное копирование открытой и закрытой базы данных

Резервное копировние открытой базы данных (open backup), также называемое оперативным (online backup) или горячим резервным копировние (hot/warm backup), подразумевает создание резервных копий при открытой и доступной для пользователей базе данных. Выполнять оперативное резервное копирование всей базы данных (равно как и только принадлежащего ей табличного пространства или файла данных) можно только в том случае, если база данных функционирует в режиме ARCHIVELOG. Проводить его, когда база данных функционирует в режиме NOARCHIVELOG, нельзя.

Резервное копирование закрытой базы данных (closed backup), также называемое холодным резервным копированием (cold backup), подразумевает создание резервных копий при закрытой (остановленной) базе данных. Такое резервное копирование всегда приводит к созданию согласованных резервных копий, если только база данных не была остановлена командой SHUTDOWN ABORT.

Физическое и логическое резервное копирование

С технической точки зрения процедуры резервного копирования Oracle можно поделить на логические и физические. Под логическим резервным копированием (logical backup) подразумевается создание резервных копий с помощью утилиты Data Pump Export, которые содержат логические объекты наподобие таблиц и процедур. Эти резервные копии сохраняются в особом двоичном формате, и данные из них могу извлекаться только посредством утилиты Data Pump Import.

Под физическим резервным копирование (physical backup) подразумевается создание резервных копий ключевых файлов базы данных Oracle, т.е. файлов данных, файлов архивных журналов повторного выполнения и управляющих файлов. Эти резервные копии могут сохраняться как на дисковых, так и на ленточных накопителях

Уровни резервного копирования

Ниже перечислены уровни, на которых допускается выполнять резервное копирование баз данных Oracle:

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

Резервное копирование БД

Во время работы с Системой рекомендуется регулярно (например, еженедельно) делать резервную копию базы данных на внешний носитель (например, на CD- или DVD-диск). Создание резервной копии базы данных поможет быстро восстановить всю информацию в случае поломки ЭВМ или форс-мажора.

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

Для создания резервной копии выберите пункт меню Администрирование->Резервное копирование. В открывшейся форме необходимо выбрать или задать папку для сохранения резервной копии:

Папка по умолчанию — это папка с именем MSSQL\BACKUP находящаяся в директории с установленным сервером баз данных.

Путь должен быть локальным для компьютера, на котором установлен сервер баз данных.

При создании резервной копии сохраните версию системы ЛЭРС УЧЁТ, для которой архивируется база данных. Версия понадобится при восстановлении БД.

Версию системы можно посмотреть выбрав пункт меню Поддержка->О программе.

Восстановление базы данных из резервной копии изложено в разделе ‘Восстановление БД’.

Проверить после создания — если установлен этот признак, то сразу после создания выполняется проверка созданной копии.

Для того, чтобы воспользоваться этим механизмом, учётной записи, под которой запущен сервер ЛЭРС УЧЁТ, потребуется разрешение на создание БД (CREATE DATABASE). Оно нужно не смотря на то, что физически база данных не будет создана, а только будет выполнена проверка.

Если этого разрешения нет, при проверке созданной копии БД будет выдано сообщение об ошибке:

Невозможно проверить резервную копию, так как у пользователя, под которым запущен сервер ЛЭРС УЧЁТ, отсутствуют необходимые разрешения.

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

Действия для выдачи разрешения описаны в статье Как дать пользователю сервера разрешения на проверку созданной резервной копии.

Наверх

 

Резервное копирование баз данных Microsoft SQL Server.

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

Модели восстановления

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

Как известно, база данных MS SQL состоит из двух частей: собственно, базы данных и лога транзакций к ней. База данных содержит пользовательские и служебные данные на текущий момент времени, лог транзакций включает в себя историю всех изменений базы данных за определенный период, располагая логом транзакций мы можем откатить состояние базы на любой произвольный момент времени.

Для использования в производственных средах предлагается две модели восстановления: простая и полная. Существует также модель с неполным протоколированием, но она рекомендуется только как дополнение к полной модели на период крупномасштабных массовых операций, когда нет необходимости восстановления базы на определенный момент времени.

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

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

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

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

Виды резервных копий

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

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

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

Резервная копия журнала транзакций — применяется только при полной модели восстановления и содержит копию журнала транзакций начиная с момента создания предыдущей копии.

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

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

Журнал транзакций

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

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

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

Та часть журнала, которая содержит активные транзакции и используется для восстановления данных называется активной частью журнала. Она начинается с номера, который называется минимальным номером восстановления (MinLSN).

В простейшем случае MinLSN — это номер записи первой незавершенной транзакции. Если посмотреть на рисунок выше, то открыв синюю транзакцию мы получим MinLSN равную 321, после ее фиксации в записи 324, номер MinLSN изменится на 323, что будет соответствовать номеру зеленой, еще не зафиксированной, транзакции.

На практике все немного сложнее, например, данные закрытой синей транзакции могут быть еще не сброшены на диск и перемещение MinLSN на 323 сделает восстановление этой операции невозможной. Для того, чтобы избежать таких ситуации было введено понятие контрольной точки. Контрольная точка создается автоматически при наступлении следующих условий:

  • При явном выполнении инструкции CHECKPOINT. Контрольная точка срабатывает в текущей базе данных соединения.
  • При выполнении в базе данных операции с минимальной регистрацией, например, при выполнении операции массового копирования для базы данных, на которую распространяется модель восстановления с неполным протоколированием.
  • При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.
  • При остановке экземпляра SQL Server с помощью инструкции SHUTDOWN или при остановке службы SQL Server (MSSQLSERVER). И в том, и в другом случае будет создана контрольная точка каждой базы данных в экземпляре SQL Server.
  • Если экземпляр SQL Server периодически создает в каждой базе данных автоматические контрольные точки для сокращения времени восстановления базы данных.
  • При создании резервной копии базы данных.
  • При выполнении действия, требующего отключения базы данных. Примерами могут служить присвоение параметру AUTO_CLOSE значения ON и закрытие последнего соединения пользователя с базой данных или изменение параметра базы данных, требующее перезапуска базы данных.

В зависимости от того, какое событие произошло раньше, MinLSN будет присвоено значение либо номера записи контрольной точки, либо начала самой старой незавершенной транзакции.

Усечение журнала транзакций

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

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

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

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

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

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

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

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

Простая модель восстановления

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

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

Полная модель восстановления

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

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

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

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

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

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

С другой стороны, если одна из копий лога транзакций будет повреждена, скажем, предпоследняя, то восстановить данные мы сможем только на момент последней резервной копии + период в неповрежденной цепочке копий журналов. Например, если журналы делались в 12, 14 и 16 часов и поврежден журнал, созданный в 14 часов, то располагая суточной копией мы сможем восстановить базу до момента окончания непрерывной цепочки, т.е. до 12 часов.

источник: http://interface31.ru/tech_it/2015/02/rezervnoe-kopirovanie-baz-dannyh-m…

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

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

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

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

При включении режима копирования журналов транзакций Veeam Backup & Replication создает 2 задания, связанных друг с другом:

  • обычное задание резервного копирования;
  • вспомогательное задание, которое копирует журналы транзакций баз данных Microsoft SQL Server.

Обычное задание резервного копирования запускается по расписанию. Оно создает резервную копию на уровне образа и сохраняет резервную копию в репозитории. После успешного создания резервной копии Veeam Backup & Replication обрезает журналы транзакций на виртуализованном сервере Microsoft SQL Server.

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

Журналы транзакций копируются в репозиторий и сохраняются в файлах формата VLB рядом с файлами резервных копий. Для копирования журналов транзакций Veeam Backup & Replication использует серверы доставки (shipping servers) — машины под управлением Microsoft Windows, добавленные в инфраструктуру резервного копирования. Вы можете самостоятельно указать, какие серверы доставки вы хотите использовать или позволить Veeam Backup & Replication самостоятельно выбрать нужные серверы для копирования журналов транзакций.

Для восстановления баз данных Veeam Backup & Replication предлагает отдельный инструмент — Veeam Explorer for Microsoft SQL. Veeam Explorer for Microsoft SQL полностью интегрирован с Veeam Backup & Replication. Инструмент устанавливается автоматически при развертывании Veeam Backup & Replication.

Veeam Explorer for Microsoft SQL предлагает ряд сценариев восстановления:

  • восстановление Microsoft SQL Server на определенную точку или определенную транзакцию.
  • восстановление Microsoft SQL Server на определенную точку или определенную транзакцию и экспорт в нужное местоположение.

В этом разделе

Условия выполнения операции

Убедитесь, что для баз данных на Microsoft SQL Server используется модель полного восстановления (Full) или модель восстановления с неполным протоколированием (Bulk-logged). Если для базы данных используется простая модель восстановления (Simple), Veeam Backup & Replication не сможет обнаружить базы данных и обработать журналы транзакций.

Основные действия

Шаг 1. Создайте задание резервного копирования для виртуализованного сервера Microsoft SQL Server

  1. Сконфигурируйте задание резервного копирования для виртуальной машины, на которой установлен Microsoft SQL Server.
  2. На шаге мастера Guest Processing установите флаг Enable application-aware processing.

В разделе VM Guest OS credentials укажите данные учетной записи пользователя гостевой ОС виртуальной машины. Учетная запись должна иметь права sysadmin на Microsoft SQL Server. В противном случае Veeam Explorer для Microsoft SQL Server не сможет автоматически обнаружить базы данных Microsoft SQL Server в созданных резервных копиях.

  1. Нажмите Applications.
  2. Выберите в списке нужную виртуальную машину и нажмите Edit.
  3. Убедитесь, что на вкладке General в разделе Transaction logs выбрана опция Process transaction logs with this job.

  1. Перейдите на вкладку SQL.
  2. Выберите опцию Backup logs periodically.
  3. В поле Backup logs every <N> minutes укажите, как часто вы хотите копировать журналы транзакций с Microsoft SQL Server в репозиторий. По умолчанию, Veeam Backup & Replication запускает новый цикл копирования каждые 15 минут.
  4. В секции Retain log backups укажите, как долго вы хотите хранить журналы транзакций.
  • Выберите опцию Until the corresponding image-level backup is deleted, если вы хотите хранить журналы до тех пор, пока предшествующая точка восстановления не будет удалена из цепочки резервных копий.
  • Выберите опцию Keep only last … days, если вы хотите хранить журналы транзакций определенное количество дней. Укажите, какое количество дней вы хотите хранить журналы транзакций.
  1. В поле Log shipping servers оставьте выбранной опцию Automatic selection. Veeam Backup & Replication автоматически определит наименее загруженную машину под управлением Microsoft Windows в инфраструктуре резервного копирования и будет использовать ее для копирования журналов транзакций.

  1. На шаге Schedule установите флаг Run the job automatically. Если вы не установите эту опцию, задание резервного копирования не сможет автоматически копировать журналы транзакций в репозиторий.
  2. Сохраните настройки задания и запустите его. Veeam Backup & Replication создаст полную резервную копию виртуальной машины, на которой установлен Microsoft SQL Server.
  3. При включении режима копирования журналов транзакций создается 2 задания резервного копирования – основное и вспомогательное. Чтобы увидеть созданные задания, откройте представление Home и щелкните по узлу Last 24 hours в панели инструментов.

  1. Выполните какую-либо транзакцию в базе данных на виртуализованном сервере Microsoft SQL Server. Например, если вы используете тестовую базу данных, вы можете вручную запустить простой сценарий добавления записи или удаления записи в/из базы данных.
  2. Убедитесь, что интервал времени, который вы указали в поле Backup logs every <N> minutes, истек. По прошествии этого времени Veeam Backup & Replication запустит новый цикл копирования журналов транзакций.

Журналы транзакций будут скопированы и сохранены в файле формата VLB рядом с цепочкой резервных копий в репозитории.

Шаг 2. Восстановите базу данных на определенную транзакцию

  1. Откройте представление Backup & Replication.
  2. В иерархии объектов щелкните по узлу Backups.
  3. В рабочей области разверните задание резервного копирования, щелкните правой кнопкой мыши по виртуальной машине и выберите Restore application items > Microsoft SQL Server databases.

  1. Пройдите по шагам мастера Microsoft SQL Server Database Restore: выберите нужную точку восстановления и укажите причину восстановления базы данных. На последнем шаге мастера нажмите Finish.

Veeam Backup & Replication автоматически обнаружит базу данных в резервной копии и подсоединит ее к вспомогательному серверу Microsoft SQL Server. По умолчанию в роли вспомогательного сервера Microsoft SQL Server используется сервер, на котором развернута база даных Veeam Backup & Replication. Затем Veeam Backup & Replication запустит Veeam Explorer для Microsoft SQL и откроет в нем обнаруженную базу данных.

  1. Найдите нужную базу данных в панели слева, щелкните по ней и выберите Restore point-in-time state to <Microsoft SQL Server\Instance Name>.

  1. Veeam Backup & Replication запустит мастер восстановления баз данных. На шаге Specify restore point выберите Restore to a specific point in time. Чтобы выбрать состояние базы данных, перетащите бегунок в нужное место.
  2. Установите флаг Perform restore to the specific transaction и нажмите Next.

  1. На шаге Fine-tune the restore point выберите нужную транзакцию и нажмите Restore.
  2. Veeam Backup & Replication восстановит базу данных на выбранную транзакцию. После завершения процесса восстановления Veeam Explorer для Microsoft SQL Server покажет всплывающее сообщение с результатами операции восстановления.

Заключительные действия

Проверьте базу данных на виртуализованном сервере Microsoft SQL Server и убедитесь, что она восстановлена в требуемое состояние.

Настройка резервного копирования 1С + MSSQL

Резервное копирование баз 1С происходит стандартными планами обслуживания СУБД MSSQL. Система позволяет делать надежные полные, а также дифференциальные копии баз данных. Процесс резервного копирования проходит незаметно для клиента и может выполняться в рабочее время без остановки работы пользователей в 1С.

Если вам необходимо организовать резервное копирование 1С, мы предоставляем его бесплатно в рамках услуги аренда сервера 1С.

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

  • Обновление статистики
  • Очистка процедурного КЭШа
  • Реорганизация индекса
  • Перестроение индекса

В нашей инструкции мы рассмотрим следующий план резервного копирования и регламентных операций с СУБД.

Субпланы резервного копирования

Daily_Full — Ежедневно в 0:00, кроме воскресенья. Полная резервная копия баз, реорганизация индексов, обновление статистик, очистка процедурного кэша.

Daily_diff — С понедельника по пятницу дважды в день, в 12.00 и 17:00. Дифференциальная копия баз.

Daily_log — С понедельника по пятницу каждые 15 минут с 8.00 до 19.00. Копия логов.

Weekly — Каждое воскресенье в 0.00. Полная резервная копия баз. Перестроение индексов.

Порядок действий:

  1. Необходимо запустить Microsoft SQL Server Management Studio и выполнить подключение к серверу.
  2. Для ВСЕХ пользовательских баз данных отключить автоматическое обновление индексов. Это связано с тем, что обновление индексов будет производиться по указанному нами расписанию.
    1. Открываем список баз данных, выделяем базу и вызываем правой кнопкой мыши контекстное меню.
    2. Открываем опции базы, меняем значение параметра Auto update statistics с true на false.
  3. Создаем новый план обслуживания Maintenance:
  4. Корректируем имя субплана и настраиваем расписание. Двойной клик по имени Subplan_1.

    Пример расписания:

    При такой настройке расписания задача будет выполняться ежедневно в 0:00, кроме воскресенья.

    ВАЖНО! Пояснение по переводу режимов восстановления.

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

  5. При работе с индексами баз данных желательно перевести пользовательские базы из режима восстановления FULL в режим SIMPLE. Для этого добавляем в субплан задачу Execute T-SQL Statement task.
    1. В настройках задачи добавляем код:
      DECLARE @name VARCHAR(50)
      DECLARE db_cursor CURSOR FOR
      SELECT name
      FROM master.dbo.sysdatabases
      WHERE name NOT IN ('master','model','msdb','tempdb')
      
      OPEN db_cursor
      FETCH NEXT FROM db_cursor INTO @name
      WHILE @@FETCH_STATUS = 0
      BEGIN
       EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY SIMPLE WITH NO_WAIT')
       FETCH NEXT FROM db_cursor INTO @name
      END
  6. Добавляем задачу реорганизации индексов:
    1. В настройках задачи выбираем реорганизацию всех пользовательских баз:
  7. После реорганизации индексов следует провести обновление статистики пользовательских баз:
    1. В настройках выбираем обновление всей статистики всех пользовательских баз с полным сканированием:
  8. Сбрасываем процедурный кэш SQL-сервера и возвращаем пользовательские базы из режима восстановления SIMPLE в режим FULL. Для этого добавляем в субплан задачу Execute T-SQL Statement task.
    1. В настройках задачи добавляем код:
      DBCC FREEPROCCACHE
      
      DECLARE @name VARCHAR(50)
      DECLARE db_cursor CURSOR FOR
      SELECT name
      FROM master.dbo.sysdatabases
      WHERE name NOT IN ('master','model','msdb','tempdb')
      
      OPEN db_cursor
      FETCH NEXT FROM db_cursor INTO @name
      WHILE @@FETCH_STATUS = 0
      BEGIN
       EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY FULL WITH NO_WAIT')
       FETCH NEXT FROM db_cursor INTO @name
      END
      
  9. Теперь необходимо добавить в субплан задачи очистки. Эти задачи способны обрабатывать только один тип файлов резервных копий. Так как создается 2 типа файлов (bak и trn), задания делаем тоже два.
    1. В настройках задания указываем путь к резервным копиям, возраст копий для удаления (4 недели) и расширение файлов.
    2. Резервные копии складываются в отдельные папки для каждой базы, поэтому включаем поиск в подкаталогах первого уровня:
    3. Настройки второй задачи отличаются расширением удаляемых файлов: trn.
  10. После удаления устаревших резервных копий добавляем задачу создания новой полной резервной копии:
    1. Настраиваем добавленное задание:
    2. Указываем тип backup Full, указываем пункт все пользовательские базы без игнорирования отключенных баз.
    3. Ставим время устаревания резервных копий 14 дней.
    4. Указываем создание отдельных файлов для каждой базы данных с созданием отдельных папок для каждой базы, указываем путь для сохранения (локальный или сетевой). Расширение файлов резервных копий bak.
    5. Включаем проверку целостности резервных копий (Verify backup integrity), включаем сжатие резервных копий (Compress backup).
  11. Теперь необходимо связать последовательно все задачи. Для этого необходимо выделить первую, нажать на стрелке внизу задачи и нажать на следующей.
    1. Добавляем субпланы Daily_diff и Daily_log:
    2. Расписание и настройки для Daily_diff:

      Данный субплан будет выполняться с понедельника по пятницу дважды в день, в 12.00 и 17:00.

    3. Добавляем задачу создания разностной резервной копии:
    4. Настройки для задачи резервирования в субплане Daily_diff аналогичны таковым в Daily_full, за исключением типа резервирования: Differential.
    5. Расписание и настройки для Daily_log:

      Расписание задачи настроено на выполнение с понедельника по пятницу каждые 15 минут с 8.00 до 19.00.

  12. Добавляем задачу создания резервной копии.

    Настройки задачи резервирования log отличаются типом (transaction log) и расширением (trn) резервных копий.

  13. Создадим субплан Weekly еженедельного обслуживания:
    1. Настраиваем расписание:

      Задача будет запускаться каждое воскресенье в 0.00.

    2. Переводим пользовательские базы из режима восстановления FULL в режим SIMPLE. Для этого добавляем в субплан задачу Execute T-SQL Statement task.
    3. В настройках задачи добавляем код:
      DECLARE @name VARCHAR(50)
      DECLARE db_cursor CURSOR FOR
      SELECT name
      FROM master.dbo.sysdatabases
      WHERE name NOT IN ('master','model','msdb','tempdb')
      
      OPEN db_cursor
      FETCH NEXT FROM db_cursor INTO @name
      WHILE @@FETCH_STATUS = 0
      BEGIN
       EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY SIMPLE WITH NO_WAIT')
       FETCH NEXT FROM db_cursor INTO @name
      END
      
    4. Добавляем задачу перестроения индексов:
    5. В настройках задачи выбираем перестроение индексов всех пользовательских баз:
    6. Сбрасываем процедурный кэш SQL-сервера и возвращаем пользовательские базы из режима восстановления SIMPLE в режим FULL. Для этого добавляем в субплан задачу Execute T-SQL Statement task.
    7. В настройках задачи добавляем код:
      DBCC FREEPROCCACHE
      
      DECLARE @name VARCHAR(50)
      DECLARE db_cursor CURSOR FOR
      SELECT name
      FROM master.dbo.sysdatabases
      WHERE name NOT IN ('master','model','msdb','tempdb')
      
      OPEN db_cursor
      FETCH NEXT FROM db_cursor INTO @name
      WHILE @@FETCH_STATUS = 0
      BEGIN
       EXEC('ALTER DATABASE ['+@name+'] SET RECOVERY FULL WITH NO_WAIT')
       FETCH NEXT FROM db_cursor INTO @name
      END
      
    8. Так как план еженедельного обслуживания не выполняется в воскресенье, добавим задачу создания полной резервной копии пользовательских баз:
    9. Настраиваем добавленное задание:
      • Ставим время устаревания резервных копий 14 дней.
      • Включаем проверку целостности резервных копий (Verify backup integrity), включаем сжатие резервных копий (Compress backup).
      • Указываем создание отдельных файлов для каждой базы данных с созданием отдельных папок для каждой базы, указываем путь для сохранения (локальный или сетевой). Расширение файлов резервных копий bak.
    10. Указываем тип backup Full, указываем пункт все пользовательские базы без игнорирования отключенных баз.
    11. Теперь необходимо связать последовательно все задачи. Для этого необходимо выделить первую, нажать на стрелке внизу задачи и нажать на следующей.

Резервное копирование и восстановление базы данных PostGres с помощью pgAdmin 4

В данной статье я покажу вам как сделать резервную копию (backup) и восстановить (restore) базу данных PostGreSQL используя инструмент pgAdmin.

Backup

Резервное коипрование (backup) это копирование (copy) данных в вашей базе данных, и расположить их в безопасном месте, в случае база данных сломается по какой-либо причине, например сломается жесткий диск сервера. Резервное коипрование (Backup) может помочь вам восстановить (restore) данные.

В основном имеются 2 способа копирования:

  1. Физическое резервное копирование (Physical backups)
  2. Логическое резервное копирование (Logical backups)

Физическое резервное копирование​​​​​​​ (Physical backups): Ваша база данных установлена на сервере, ее данные сохранены в файлах. Таким образом, для резервного копирования нужно только скопировать все эти файлы и поместить их в безопасное место (возможно, на другой жесткий диск).

Логическое резервное копирование (Logical backups): Это способ копирования части данных с помощью инструмента, предоставляемого базой данных, которой вы пользуетесь. Например, вы хотите сделать резервную копию данных нескольких таблиц или некоторых схем (Schema), полученный результат представляет собой один или несколько файлов.

Restore

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

2- Резервное копирование(Backup)

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

Есть много видов формата (format), когда вы совершаете резервное копирование, например Custom, Tar, Directory, Plain. Но больше всех предпочитается формат Custom, вашим результатом будет файл с расширением это backup.

OK, выберите формат Custom, выберите местоположение, и название файла, который будет создан…

После успешного процесса резервного копирования, у вас будет файл:

3- Восстановление (Restore)

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

Для восстановления, на pgAdmin создайте пустую базу данных.

Например я создал базу данных с названием mytestdb2.

База данных mytestdb2 создана, на самом деле она является пустой базой данных, она не имеет таблицы или какие-либо объекты.

Используйте функцию Restore для восстановление данной базы данных из файла, для которого вы создали резервную копию.

Успешный процесс Restore:

Резервное копирование MySQL. Бэкап MySQL. Сделать бэкап MySQL

Резервное копирование и восстановление баз MySQL

В данном документе подробно рассматриваются принципы и процедуры, которые необходимо соблюдать для реализации стратегии резервного копирования MySQL на уровне предприятия при использовании агента Bacula Enterprise Edition для MySQL.

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

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

Резервное копирование MySQL доступно для платформ Linux 32 и 64 бита (платформы Debian, Ubuntu, CentOS и др.), и поддерживает MySQL 4.0.x, 4.1.x, 5.0.x, 5.5.x, 5.6.x.

Как сделать бэкап MySQL: дамп или бинарный лог?

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

 

Возможности автоматического бэкапа MySQLДамп файлБинарный лог
Возможность восстановления единичного объекта MySQL (таблица, схема…)Да[1]Нет
Скорость резервного копирования MySQLМедленноБыстро
Скорость восстановления MySQLОчень медленноБыстро
Размер бэкапа базы MySQLМаленькийБольшой
Возможность восстановления MySQL до контрольной точкиДаДа
Поддержка инкрементального/дифференциального бэкапа MySQLДаДа
Онлайн бэкап MySQLДаДа
СогласованностьДаДа
Восстановление MySQL до предыдущей основной версииДа[2]Нет
Возможность восстановить MySQL до новой основной версииДаНет

[1] Чтобы восстановить единичный объект MySQL, необходимо отредактировать дамп файл.

[2] Чтобы восстановить базу MySQL до предыдущей версии, Вам, возможно, потребуется отредактировать SQL файл, если вы используете функции, недоступные в предыдущей версии. Как правило, восстановление MySQL до предыдущей версии не поддерживается и не гарантируется.

Рисунок 1: Связь между бэкапом и бинарными логами

Автоматический бэкап MySQL с внутренним агентом

Автоматический бэкап базы данных MySQL в режиме дампа

На протяжении всего срока существования БД MySQL создает логи, которые можно использовать для репликации и/или защиты БД с помощью технологии P.I.T.R (восстановление MySQL до заданной контрольной точки).
По умолчанию агент MySQL создает дамп каждой БД отдельно. Это значит, что, если вам нужно восстановить весь сервер, все БД будут согласованы по-отдельности, но их резервные копии не не будут создаваться в одно и тоже время. Значит базы данных MySQL не будут согласованы глобально. Чтобы решить данную проблему, агент для резервного копирования MySQL также будет сохранять лог файлы, создаваемые во время резервного копирования. Эти лог файлы можно будет считать впоследствии, чтобы гарантировать согласованность баз данных на определенный момент времени.

На рисунке 1, показан процесс создания бэкапов баз данных MySQL БД1, БД2 и БД3 (процесс занимает несколько часов). Во время данного процесса генерируются 3 лог файла. Эти файлы включаются в полный бэкап MySQL. Следующий инкрементальный или дифференциальный бэкап MySQL сохранит только бинарные логи, созданные после полного бэкапа. Чтобы гарантировать, что только одна копия каждого лог файла включена в бэкап, необходимо активировать функцию Accurate для выполнения задачи.

В примере выше, первый инкрементальный бэкап, созданный после полного бэкапа, будет включать логи 5 и 6, второй инкрементальный бэкап будет включать логи 7 и 8. Дифференциальный бэкап включал бы лог файлы 5, 6, 7 и 8.
При использовании функции all_databases будут создаваться дампы всех БД одновременно. При этом лог файлы , созданные по завершении полного бэкапа, не будут включаться в него, а логи, сгенерированные до завершения задачи, будут включены в полный бэкап. В примере на рисунке 2 показано, что полный бэкап сгенерирует единый дамп файл «all-databases.sql», который будет включать лог файлы 2 и 3. Первый последующий инкрементальный бэкап будет включать логи 4, 5 и 6.

Рисунок 2: Связь между функцией all_databases и бинарными логами

Как сделать бэкап базы данных MySQL в режиме бинарных логов

В режиме бинарных логов инструмент MySQL использует программу Percona XtraBackup, которая представляет собой утилиту для создания горячего бэкапа серверов MySQL, которая не блокирует БД во время резервного копирования. Технология Percona использует методы, гарантирующие согласованность всего бэкапа MySQL.

Утилита бэкапа MySQL может создавать резервные копии данных из хранилищ InnoDB, XtraDB, и MyISAM на немодифицированных серверах MySQL 5.0, 5.1 и 5.5, также как это делает утилита Percona Server с XtraDB.
Более подробную информацию об утилите Percona вы найдете на сайте:

http://www.percona.com/doc/percona-xtrabackup.

Оценка информации при бэкапе таблицы MySQL

Команда estimate позволяет отобразить всю информацию, найденную агентом MySQL. В случае режима дампа, наше ПО не может оценить размер дамп файла для БД. Вместо этого оно отобразит размер БД.

Информация о резервном копировании MySQL в режиме дампа

Агент MySQL сгенерирует следующие файлы в каталоге Bacula для сервера, имеющего единую БД “test”.

 

ФайлТипПояснение
global-grants.sqlглобальныйСписок пользователей, их пароли и специальные функции
settings.txtглобальныйТекущие переменные для mysql сервера
my.cnfглобальныйКонфигурация MySQL
createdb.sqlБДСкрипт создания БД
schema.sqlБДСкрипт создания схемы БД
data.sqlБДДанные БД в формате дампа
grants.sqlБДСписок всех пользователей, связанных с БД

Таблица 2. Содержание бэкапа MySQL в режиме дампа

Восстановление MySQL

Bacula позволяет восстановить бэкап MySQL в нескольких режимах восстановления:

  • Восстановление MySQL из дамп файла или бинарных логов
  • Восстановление пользователей и ролей
  • Восстановление единой БД MySQL
  • Восстановление MySQL до контрольной точки

Чтобы восстановить бэкап MySQL в режиме бинарных логов, агент использует утилиту percona.

Рисунок 3: Содержимое сервера во время восстановления MySQL

Рисунок 4: Содержимое БД во время восстановления MySQL

Как сделать бэкап базы данных MySQL без использования плагина бесплатно

Создание дампа базы данных MySQL

Данный способ полностью бесплатен, поскольку позволяет делать бэкап MySQL с помощью open source версии Bacula Community и без дополнительных плагинов. Для резервного копирования небольших баз данных MySQL можно использовать простые bash-скрипты для резервного копирования баз данных. Для случая с резервным копированием баз MySQL можно сделать скрипт бэкапа MySQL, который будет запускаться на клиенте и делать dump базы данных MySQL.

#!/bin/bash  

mysqldump -uuser -ppassword —all-databases | gzip > /opt/mysql_backup/backup.`date +%F`.sql.gz 

find /home/bacula-backup/ -type f -mtime +3 -exec rm -f {} \;

Этот скрипт бэкапа MySQL сохранит дамп всех БД MySQL в директорию /opt/mysql_backup/ из которой мы и будем делать резервные копии дампов базы данных, при помощи директивы Client Run Before Job.

Пример задачи на бэкап базы MySQL:

Job {

   Name = «BackupSmallMysqlServer»

   Type = Backup

   Level = Incremental

   Client = mysqlserver1

   FileSet = «mysqlserver»  

   Schedule = «WeeklyCycle»  

   Storage = SD1  

   Messages = Standard

   Pool = Mysql

   ClientRunBeforeJob = «/opt/sbin/mysql.sh»

   SpoolAttributes = yes

   Priority = 10

   Write Bootstrap = «/var/lib/bacula/%c.bsr»

     }

   FileSet {  

     Name = «mysqlserver»  

     Include {    

        Options {      

          signature = MD5      

          compression = GZIP    

                }

     File = /opt/mysql_backup/  

              }

            }

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

Как сделать бэкап нагруженных баз данных MySQL?

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

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

Для нагруженных систем резервное копирование MySQL необходимо делать именно для Slave базы данных.

полных резервных копий базы данных (SQL Server) — SQL Server

  • 3 минуты на чтение

В этой статье

Применимо к: SQL Server (все поддерживаемые версии)

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

Подсказка

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

В этой теме:

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

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

, пример (Transact-SQL)

В следующем примере показано, как создать полную резервную копию базы данных, используя WITH FORMAT для перезаписи любых существующих резервных копий и создания нового набора носителей.

  - Резервное копирование базы данных AdventureWorks2012 на новый набор носителей.
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
    НА ДИСК = 'Z: \ SQLServerBackups \ AdventureWorksSimpleRM.bak'
    С ФОРМАТОМ;
ИДТИ
  

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

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

Для получения информации о том, как создавать резервные копии журналов, см. Резервные копии журналов транзакций (SQL Server).

, пример (Transact-SQL)

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

  USE master;
ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;
ИДТИ
- Сделайте резервную копию базы данных AdventureWorks2012 на новый набор носителей (резервный набор 1).
РЕЗЕРВНАЯ БАЗА ДАННЫХ AdventureWorks2012
  НА ДИСК = 'Z: \ SQLServerBackups \ AdventureWorks2012FullRM.bak'
  С ФОРМАТОМ;
ИДТИ
--Создайте обычную резервную копию журнала (набор резервных копий 2).
РЕЗЕРВНЫЙ ЖУРНАЛ AdventureWorks2012 НА ДИСК = 'Z: \ SQLServerBackups \ AdventureWorks2012FullRM.bak';
ИДТИ
  

Используйте полную резервную копию базы данных для восстановления базы данных

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

Для получения дополнительной информации см. Полное восстановление базы данных (простая модель восстановления) или Полное восстановление базы данных (модель полного восстановления).

Для создания полной резервной копии базы данных

Для планирования заданий резервного копирования

Используйте мастер плана обслуживания

См. Также

Резервное копирование и восстановление баз данных SQL Server
Обзор резервного копирования (SQL Server)
Резервное копирование и восстановление баз данных служб Analysis Services

Программное обеспечение для резервного копирования базы данных для Windows и Linux

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

Handy Backup — это программа профессионального уровня, обеспечивающая резервное копирование и восстановление баз данных для различных типов СУБД. Наряду с базами данных Handy Backup может сохранять данные любых других типов, от файлов и папок до статического содержимого веб-сайтов, данных CMS и облачных учетных записей!

Список поддерживаемых баз данных

Этот инструмент делает снимки баз данных и таблиц MySQL, формируя читаемые наборы команд SQL, позволяющие восстанавливать исходные наборы данных MySQL.

Выделенный инструмент может выполнять резервное копирование Microsoft SQL Server любой версии (MSSQL 2016, 2014). Этот инструмент может сохранять целые базы данных, таблицы, SPFILE и Controlfile.

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

Функция резервного копирования Oracle основана на внутренней служебной программе резервного копирования RMAN, обеспечивая полную совместимость с Oracle API. Он может создавать резервные копии и восстанавливать данные Oracle изначально.

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

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

Подключаемый модуль для резервного копирования файлов и таблиц IBM Notes (ранее Lotus Notes и Domino) обеспечивает быстрый и безопасный доступ к информации базы данных IBM Notes и эффективное восстановление сделанных снимков.

Используйте резервную копию базы данных ODBC для любой СУБД со стандартным универсальным инструментом под названием «База данных». С помощью такой функции вы можете создавать резервные копии некоторых баз данных SQL или не SQL:

Существует два основных подхода к резервному копированию баз данных:

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

    Например, если у вас есть конфигурация репликации Master-to-Slave, вы можете безопасно выключить Slave, создать резервную копию его файлов и затем запустить его снова.

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

Запланируйте резервное копирование, включите уведомления по электронной почте — и всегда знайте, что ваши данные защищены.

Репликация

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

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

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

Кластеризация

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

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

Handy Backup существует в двух редакциях бизнес-уровня, каждая из которых поставляется с полным набором подключаемых модулей для резервного копирования баз данных и другими полезными опциями.Для резервного копирования баз данных попробуйте выпуски Small Business или Server Network. Бесплатная 30-дневная пробная версия!

Рекомендуемое решение

Версия 8.3.1, построено 11 августа 2021 г. 111 МБ
Программное обеспечение для резервного копирования от ООО «Новософт». 249 долларов США за лицензию.

Для использования подключаемых модулей резервного копирования базы данных вам потребуется Small Business edition нашего программного обеспечения. Все плагины для источников данных и хранилищ для резервного копирования серверов малого бизнеса!

Рекомендуемое решение

Версия 8.3.1, построен 11 августа 2021 года. 111 МБ
Программа резервного копирования от ООО «Новософт». 299 долларов США за лицензию.

Сделайте централизованное резервное копирование всех серверов и рабочих станций во всей сети с одной централизованной консоли с помощью Server Network edition , полного решения для сетевого резервного копирования!

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

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

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

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

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

См. Также:

Рейтинг редактора Cnet:

Выдающийся

9 Что необходимо вашей стратегии резервного копирования базы данных Потребности | Программное обеспечение безопасного облачного резервного копирования

Когда базы данных выходят из строя, это может иметь разрушительные последствия для вашей компании. Без правильной стратегии резервного копирования базы данных ваша компания может столкнуться с огромным количеством простоев, что приведет к упущенной прибыли и недовольству клиентов.Хорошая стратегия резервного копирования базы данных должна преследовать три цели: комплексное резервное копирование, быстрое резервное копирование и быстрое восстановление. Создавая свою стратегию, помните об этих 10 элементах.

1. Резервное копирование на месте

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

2. Хранение старых резервных копий

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

3. Внешнее резервное копирование

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

4. Стандарты центров обработки данных

Для безопасного хранения данных за пределами площадки требуется, чтобы выбранный вами центр обработки данных имел надлежащие меры безопасности.Поскольку в центре обработки данных будет размещаться резервная копия ваших данных, потенциально экономящая компания, безопасность — это не та область, в которой вы должны идти на компромисс. Выбранный вами центр обработки данных должен проходить ежегодный аудит SSAE 16 Type 2 — значок, свидетельствующий о том, что он соответствует отраслевым стандартам в отношении организационных средств контроля как на уровне объекта, так и на процедурном уровне или превышает их. Вот некоторые признаки качественного центра обработки данных:

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

5.Управление передачей данных

Проблемы безопасности на уровне центра обработки данных не должны быть единственными, которые вы должны учитывать при резервном копировании базы данных. Многие компании не принимают во внимание тот факт, что данные могут быть скомпрометированы до того, как они попадут в центр обработки данных. Чтобы этого не произошло, убедитесь, что данные, которые вы обновляете в центре обработки данных, также зашифрованы во время передачи. Шифрование AES, 256-битное шифрование Twofish и Triple DES — все это надежные варианты.

6. Расписание резервного копирования

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

  • Как часто происходят изменения в системе?
  • Когда люди обращаются к базе данных?
  • Сколько места потребуется для этой резервной копии?

7. Автоматическое резервное копирование в облако

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

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

8. Быстрое и простое восстановление

Резервное копирование не принесет пользы вашему бизнесу, если вы не знаете, как восстановить данные.Независимо от того, как вы выполняете резервное копирование, вам нужно знать, как восстановить резервную копию в случае сбоя, чтобы минимизировать время простоя. Если вы работаете с поставщиком облачного резервного копирования, например Nordic Backup , вы можете перенести резервную копию в онлайн как виртуальный сервер, пока ваши серверы снова не заработают (обычно в течение 1-дневного окна обслуживания), или вы даже можете может превентивно виртуализировать ваши серверы , чтобы не было времени ожидания для восстановления данных.

9.Резервное тестирование

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

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

Как сделать резервную копию базы данных MySQL (2 невероятно простых метода)

Нужна резервная копия базы данных MySQL? Большинство хостов WordPress, включая Kinsta, имеют автоматическое резервное копирование, поэтому вам не нужно беспокоиться о резервном копировании вручную в случае возникновения чрезвычайной ситуации.

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

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

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

Шаг 1

Войдите в phpMyAdmin. Если вы клиент Kinsta, на панели управления MyKinsta есть удобная ссылка (вместе с учетными данными) для входа в phpMyAdmin.

WordPress доступ phpMyAdmin

Если вы используете cPanel, ссылка на phpMyAdmin будет находиться в разделе «Базы данных».

cPanel phpMyAdmin

Шаг 2

Щелкните в своей базе данных WordPress. Скорее всего, название будет соответствовать названию вашего сайта или имени пользователя.

phpmyadmin база данных WordPress

Шаг 3

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

Вариант 1 — метод быстрого экспорта

Щелкните вкладку «Экспорт». Если вы собираетесь использовать свою базу данных там, где ее старая версия не существует, или если вам просто нужна резервная копия, вы можете выбрать «Быстро — отображать только минимальные параметры.Затем нажмите «Перейти».

Экспорт таблиц в phpmyadmin

Это сгенерирует файл .sql , который вы можете сохранить в качестве резервной копии или восстановить / импортировать в другом месте. Помните, что база данных WordPress содержит только информацию с вашего сайта, файлы (плагин / темы) полностью разделены и должны быть загружены и сохранены через SFTP.

Вариант 2 — Пользовательский метод экспорта

Если вы собираетесь импортировать свою базу данных в место, где она уже существует с таблицами с таким же именем, вы захотите выбрать «Пользовательский — отобразить все возможные варианты».”

экспорт phpmyadmin custom

Прокрутите вниз до раздела параметров создания объекта и выберите «Добавить оператор DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER». Это гарантирует, что он просто перезапишет существующие таблицы с тем же именем.

Подпишитесь на информационный бюллетень

Хотите узнать, как мы увеличили наш трафик более чем на 1000%?

Присоединяйтесь к 20 000+ другим, кто получает нашу еженедельную рассылку с инсайдерскими советами по WordPress!

Подпишитесь сейчас

Добавить выпадающую таблицу phpmyadmin

Затем нажмите «Перейти.Это сгенерирует файл .sql , который вы можете сохранить в качестве резервной копии или восстановить / импортировать в другом месте.

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

Если вы являетесь клиентом Kinsta, есть два варианта резервного копирования базы данных MySQL — загружаемые резервные копии и внешние резервные копии.

Резервное копирование базы данных MySQL с помощью загружаемых резервных копий

Это архивный файл ( .zip, ), содержащий весь ваш сайт WordPress. Архивный файл содержит файлы вашего веб-сайта, а также файл SQL , содержащий содержимое вашей базы данных.

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

WordPress загружаемая резервная копия.

Шаг 1

Щелкните «Создать резервную копию сейчас». Создание резервной копии может занять несколько минут в зависимости от размера вашего сайта. Когда все будет готово, вы получите сообщение через панель управления MyKinsta, а также электронное письмо со ссылкой для загрузки .

Электронная почта с возможностью загрузки резервной копии

Шаг 2

Нажмите «Загрузить резервную копию сейчас!» ссылку в электронном письме или кнопку «Загрузить резервную копию» на панели управления MyKinsta.

Загрузите резервную копию WordPress.

Резервная копия — это файл .zip . Он содержит все файлы вашего веб-сайта и файл mysql-database-backup.sql . Просто разархивируйте его, и у вас будет резервная копия базы данных MySQL.

Файл резервной копии базы данных MySQL

Резервное копирование базы данных MySQL с помощью внешних резервных копий

Наша надстройка внешнего резервного копирования позволяет настроить автоматическое резервное копирование сайтов WordPress в Amazon S3 или Google Cloud Storage. Если вы ищете удобный способ добавить автоматические внешние резервные копии без установки плагина WordPress, наша функция внешнего резервного копирования — отличный вариант.

Разрешить внешнее резервное копирование в MyKinsta.

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

Создайте резервную копию базы данных WordPress на Amazon S3 или GCS.

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


Экономьте время, деньги и повышайте производительность сайта с:

  • Мгновенная помощь от экспертов по хостингу WordPress, 24/7.
  • Интеграция Cloudflare Enterprise.
  • Глобальный охват аудитории с 28 центрами обработки данных по всему миру.
  • Оптимизация с помощью нашего встроенного мониторинга производительности приложений.

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

Общие сведения о типах резервного копирования SQL Server

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

Ниже приведены наиболее распространенные типы резервных копий, доступных в SQL Server:

  1. Полный
  2. Дифференциальный
  3. Журнал транзакций
  4. Резервная копия журнала Tail

Доступны и другие типы резервного копирования:

  1. Резервное копирование только для копирования
  2. Резервные копии файлов
  3. Частичные резервные копии.

Полное резервное копирование

Полная резервная копия, как следует из названия, создает резервную копию всего.Это основа любой резервной копии. Это полная копия, в которой хранятся все объекты базы данных: таблицы, процедуры, функции, представления, индексы и т. Д. Имея полную резервную копию, вы сможете легко восстановить базу данных в том же виде, в каком она была на момент создания. время резервного копирования.

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

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

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

BACKUP DATABASE — это команда, используемая для создания полной резервной копии базы данных. Для этого требуются как минимум два входных параметра: имя базы данных и устройство резервного копирования.

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

РЕЗЕРВНАЯ БАЗА ДАННЫХ [SQLShackDemoATC]

На ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATC.BAK ‘

С ФОРМАТОМ,

MEDIANAME =’ Native_SQLServerBackup ‘,

NAME =’ Full-SQLShackDemoATC backup ‘;

Полное резервное копирование базы данных в несколько файлов

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

РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ SQLShackDemoATC НА

ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATC_1.BAK’,

ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATC_2.BAK’,

DISK = ‘f: \ PowerSQL \ SQLShack_D.BAK ,

DISK = ‘f: \ PowerSQL \ SQLShackDemoATC_4.BAK’

WITH INIT, NAME = ‘FULL SQLShackDemoATC backup’, STATS = 5

Если вы хотите создать зеркальную копию файла резервной копии:

РЕЗЕРВНАЯ БАЗА ДАННЫХ ProdSQLShackDemo

НА ДИСК = ‘F: \ PowerSQL \ ProdSQLShackDemo_1.BAK ‘

ЗЕРКАЛО НА ДИСК =’ F: \ PowerSQL \ ProdSQLShackDemo_2.BAK ‘

С ФОРМАТОМ

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

РЕЗЕРВНАЯ БАЗА ДАННЫХ ProdSQLShackDemo

НА ДИСК = ‘F: \ PowerSQL \ ProdSQLShackDemo_1.BAK’

ЗЕРКАЛО НА ДИСК = ‘F: \ PowerSQL \ ProdSQLShackDemo_2.BAK’

ЗЕРКАЛО НА ДИСКBAK ‘

ЗЕРКАЛО НА ДИСК =’ F: \ PowerSQL \ ProdSQLShackDemo_4.BAK ‘

С ФОРМАТОМ

GO

Дифференциальное резервное копирование

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

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

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

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

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

  1. Имя базы данных
  2. Устройство резервного копирования
  3. Предложение DIFFERENTIAL

Например,

РЕЗЕРВНАЯ БАЗА ДАННЫХ [SQLShackDemoATC]

На ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATC_Diff.BAK ‘

С ДИФФЕРЕНЦИАЛОМ,

MEDIANAME =’ Native_SQLServerDiffBackup ‘,

NAME =’ Diff-SQLShackDemoATC backup ‘;

Резервное копирование журнала транзакций

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

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

Как создать резервную копию журнала транзакций с помощью T-SQL

Команда BACKUP LOG используется для резервного копирования журнала транзакций. Для инициации резервного копирования журнала транзакций требуется имя базы данных, целевое устройство и предложение TRANSACTION LOG.

РЕЗЕРВНЫЙ ЖУРНАЛ [SQLShackDemoATC]

На ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATC_Log.trn’

С

MEDIANAME = ‘Native_SQLServerLogBackup’,

AT backup = ‘Log-SQLShackDe’;

ГО

Резервное копирование хвостового журнала

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

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

USE master;

GO

— создать резервную копию журнала событий

РЕЗЕРВНЫЙ ЖУРНАЛ [SQLShackDemoATC]

НА ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATCTailLog.журнал ‘

С CONTINUE_AFTER_ERROR;

ГО

Предложение WITH CONTINUE_AFTER_ERROR заставит SQL Server сохранить файл журнала, даже если он генерирует ошибку.

Копировать_Только резервное копирование

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

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

Выполнить резервное копирование только для копирования довольно просто. Синтаксис будет выглядеть примерно так:

РЕЗЕРВНАЯ БАЗА ДАННЫХ [SQLShackDemoATC]

На ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATC_1.BAK ‘

WITH COPY_ONLY,

MEDIANAME =’ Native_SQLServerFullBackup ‘,

NAME =’ Full-SQLShackDemoATC backup ‘;

РЕЗЕРВНЫЙ ЖУРНАЛ [SQLShackDemoATC]

НА ДИСК = ‘f: \ PowerSQL \ SQLShackDemoATCCopyOnly.log’

WITH COPY_ONLY;

ГО

Команда BACKUP LOG с параметром COPY_ONLY создает резервную копию журнала только для копирования. Это не связано с усечением журнала транзакций.

Необходимо использовать опцию резервного копирования «COPY_ONLY», чтобы сохранить последовательность резервного копирования базы данных.

Частичное резервное копирование

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

Параметр READ_WRITE_FILEGROUPS используется с командой BACKUP DATABASE. Эта команда предназначена для частичного резервного копирования.Он обрабатывает резервное копирование файловых групп для чтения и записи.

SQLShackPartialBackup — это база данных, созданная с использованием первичных и вторичных файловых групп. Давайте использовать эту базу данных для этой демонстрации.

СОЗДАТЬ БАЗУ ДАННЫХ SQLShackPartialBackup НА ПЕРВИЧНОМ

(ИМЯ = N’SQLShackPartialBackup_1 ‘,

ИМЯ ФАЙЛА = N’f: \ PowerSQL \ SQLShackPartialBackup_1.mdf’,

РАЗМЕР =

КБайт, FILEGRO17 [2])

(ИМЯ = N’SQLShackPartialBackup_2 ‘,

ИМЯ ФАЙЛА = N’f: \ PowerSQL \ SQLShackPartialBackup_2.mdf ‘,

РАЗМЕР = 5000 КБ, FILEGROWTH = 1024 КБ)

ЖУРНАЛ

(ИМЯ = N’SQLShackPartialBackup_Log’,

ИМЯ ФАЙЛА = N’f: \ PowerSQL \ SQLShackPartialBackup_log.ld14f ‘,

= 10%)

ГО

Давайте изменим модель восстановления базы данных на SIMPLE, используя следующий оператор ALTER

ALTER DATABASE SQLShackPartialBackup SET ВОССТАНОВЛЕНИЕ ПРОСТОЕ

Теперь установите вторичную файловую группу в режим ТОЛЬКО ДЛЯ ЧТЕНИЯ.

ALTER DATABASE SQLShackPartialBackup MODIFY FILEGROUP [Secondary] ТОЛЬКО ДЛЯ ЧТЕНИЯ

Инициируйте резервное копирование с помощью параметра READ_WRITE_FILEGROUPS

РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ SQLShackPartialBackup READ_WRITE_FILEGROUPS

НА ДИСК = N’f: \ PowerSQL \ SQLShackPartialBackup_Full.бак ‘

ГО

На следующем снимке экрана видно, что файловая группа SQLShackPartialBackup_2 не была скопирована в процессе резервного копирования.

Резервное копирование файлов и групп файлов

Этот раздел актуален для баз данных SQL Server, содержащих несколько файлов или файловых групп. Резервные копии файлов для файловых групп, доступных только для чтения, можно комбинировать с частичными резервными копиями. Частичные резервные копии включают все файловые группы для чтения и записи и, при желании, одну или несколько файловых групп только для чтения.

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

СОЗДАТЬ БАЗУ ДАННЫХ SQLShackFileBackup НА ПЕРВИЧНОМ

(ИМЯ = N’SQLShackFileBackup_1 ‘,

ИМЯ ФАЙЛА = N’f: \ PowerSQL \ SQLShackFileBackup_1.mdf’,

SIZE = 5000KBEGROWTH, FILEGROWTH = 1024

), второй

(ИМЯ = N’SQLShackFileBackup_2 ‘,

ИМЯ ФАЙЛА = N’f: \ PowerSQL \ SQLShackFileBackup_2.ndf ‘,

РАЗМЕР = 5000 КБ, FILEGROWTH = 1024 КБ)

ЖУРНАЛ

(ИМЯ = N’SQLShackFileBackup_Log’,

ИМЯ ФАЙЛА = N’f: \ PowerSQL \ SQLShackFileBackup_Log.ld14f ‘,

= 10%)

ГО

Следующие примеры демонстрируют, как создать резервную копию файлов на уровне файлов:

РЕЗЕРВНАЯ БАЗА ДАННЫХ SQLShackFileBackup

FILE = ‘SQLShackFileBackup_1’,

FILE = ‘SQLShackFileBackup_2’

НА ДИСК = ‘f: \ PowerSQL \ SQLShackGroupfiles.бак ‘;

ГО

В следующем примере показано полное резервное копирование всех файлов как в первичной, так и в вторичной файловых группах.

РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ SQLShackFileBackup

FILEGROUP = ‘PRIMARY’,

FILEGROUP = ‘Secondary’

TO DISK = ‘f: \ PowerSQL \ SQLShackGroupfilegroup.bak’;

ГО

Параметры резервного набора

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

С опциями

Предложение WITH используется с командой BACKUP в случае, если у нас есть дополнительные требования к резервному копированию.

СЖАТИЕ: этот параметр включает сжатие резервных копий. NO_COMPRESSION явно отключает сжатие резервной копии. По умолчанию во время резервного копирования сжатие отключено.

ШИФРОВАНИЕ: алгоритм шифрования может быть указан с помощью BACKUP для защиты файлов резервных копий, хранящихся за пределами сайта. Вы можете указать NO_ENCRYPTION, если резервное шифрование не требуется.

Комплект материалов для печати Опции

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

INIT: INIT используется для создания нового набора резервных копий; NOINIT используется для добавления резервной копии к существующему набору резервных копий. Параметр NOINIT используется в основном при резервном копировании базы данных на ленточное устройство.

NAME: параметр NAME используется для идентификации резервного набора.

SKIP: параметр skip используется для пропуска проверки срока действия резервного набора данных.

NOREWIND: этот параметр используется для того, чтобы ленточное устройство оставалось открытым и готовым к использованию.

NOUNLOAD: этот параметр используется для указания SQL Server не выгружать ленту с накопителя после завершения операции резервного копирования.

СТАТИСТИКА: параметр СТАТИСТИКА полезен для получения статуса операции резервного копирования на регулярных этапах ее выполнения.

Сводка

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

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

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

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

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

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

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

На этом пока все. Следите за обновлениями!

Содержание

Список литературы


Я технолог по базам данных с более чем 11-летним богатым практическим опытом работы с технологиями баз данных.Я сертифицированный специалист Microsoft и имею степень магистра компьютерных приложений.

Моя специальность заключается в разработке и внедрении решений высокой доступности и кроссплатформенной миграции БД. В настоящее время работают над технологиями SQL Server, PowerShell, Oracle и MongoDB.

Посмотреть все сообщения от Prashanth Jayaram

Последние сообщения от Prashanth Jayaram (посмотреть все)

Как создать резервную копию и восстановить базы данных MySQL® в cPanel

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

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

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

Что такое MySQL?

MySQL — это система управления реляционными базами данных (СУБД) с открытым исходным кодом, используемая для эффективного хранения, организации и извлечения информации. cPanel и WHM используют MySQL, как и многие из самых популярных систем управления контентом и приложений электронной коммерции, включая WordPress®, Joomla, Drupal и Magento®.

MySQL хранит данные в таблицах, которые разделены на столбцы предопределенного типа данных. Отдельные записи составляют строки таблицы, и они должны соответствовать типам, определенным столбцами. Например, вот раздел таблицы сообщений из базы данных нового сайта WordPress.

Как пользователи загружают данные в MySQL и из них? В отличие от файловой системы, мы не можем просто отредактировать файл и нажать «Сохранить». Мы должны разговаривать с СУБД на ее собственном языке, который называется SQL. Чтобы сгенерировать таблицу на изображении, мы отправили следующий оператор SQL:

ВЫБРАТЬ ID, post_date, post_title, post_type, comment_count ОТ wp_posts;

Как пользователю cPanel, вам не нужно писать SQL, потому что cPanel позаботится об этом за кулисами.Однако полезно понять, что это такое, потому что резервные копии MySQL — это просто список операторов SQL.

Когда вы запускаете резервное копирование, программное обеспечение генерирует операторы, необходимые для воссоздания базы данных, и сохраняет их в файл. Это часто называют «экспортом» или «сбросом» базы данных. При восстановлении MySQL запускает эти операторы, чтобы вернуть базу данных в то состояние, в котором она была на момент создания резервной копии.

Как создать резервную копию базы данных MySQL в cPanel

Наша цель — создать дамп базы данных и загрузить полученный файл SQL на наш компьютер, где мы сможем сохранить его или переместить в более безопасное место.Это можно сделать из командной строки с помощью клиента «mysql», но резервное копирование и восстановление cPanel MySQL предлагает простой в использовании интерфейс.

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

  • Сначала выберите Backup в разделе Files на главной странице.Эта страница представляет собой полезный унифицированный интерфейс для резервного копирования файлов и баз данных, связанных с вашей учетной записью cPanel.
  • Затем найдите Download a MySQL Database Backup раздел, где вы увидите список баз данных, которые вы можете скачать.

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

Это наиболее простой способ резервного копирования MySQL в cPanel, но вы также можете использовать интегрированный инструмент администрирования phpMyAdmin для настройки параметров экспорта или резервного копирования нескольких баз данных одновременно.Вот как это сделать:

Резервное копирование базы данных в cPanel с помощью phpMyAdmin

Выберите phpMyAdmin в разделе Базы данных на главной странице cPanel.

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

В большинстве случаев настройка Quick обеспечивает оптимальную конфигурацию экспорта для резервных копий MySQL, но настройка Custom полезна для исключения таблиц, переименования экспортируемого файла или выполнения более сложной конфигурации.Если вы хотите экспортировать несколько баз данных одновременно, откройте phpMyAdmin и, не выбирая базу данных на боковой панели, щелкните вкладку Export . Метод экспорта Quick по умолчанию экспортирует все доступные базы данных. Чтобы настроить, какие базы данных экспортируются, выберите метод экспорта Custom и выберите те, для которых требуется создать резервную копию.

Планирование резервного копирования MySQL с помощью Cron в cPanel

Мы увидели, насколько просто создать резервную копию баз данных MySQL в cPanel, но что, если вы хотите автоматически создавать резервную копию базы данных по расписанию? Об этом слишком легко забыть, а планирование гарантирует, что безопасность ваших данных не будет зависеть от вашей памяти.

Для автоматизации резервного копирования MySQL вы можете использовать планировщик задач cron и инструмент командной строки «mysqldump». Перейдите на страницу cPanel Cron Jobs , которую вы найдете в разделе Advanced на главной странице.

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

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

mysqldump -u ИМЯ ПОЛЬЗОВАТЕЛЯ -p ПАРОЛЬ база данных> резервная копия базы данных.sql

Нажмите кнопку Добавить новое задание Cron , и все готово. Cron запустит резервное копирование через указанный интервал времени, сохраняя файл SQL в месте, указанном в конце команды (часть после символа>).

Чтобы узнать больше об автоматизации задач с помощью заданий cron, прочтите Как настроить задание Cron.

Как восстановить базу данных MySQL в cPanel

Чтобы восстановить базу данных, откройте интерфейс Backup , который вы найдете в разделе Files на главной странице cPanel.

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

В разделе под названием Восстановить резервную копию базы данных MySQL щелкните Выберите файл и выберите файл SQL на локальном компьютере. Щелкните Загрузить, , и cPanel импортирует файл.

Для более сложного импорта SQL или для репликации, а не для замены базы данных, вы можете использовать инструмент phpMyAdmin, описанный в предыдущем разделе. Однако страница Backup предпочтительнее для стандартного восстановления, поскольку cPanel обрабатывает префиксы базы данных и настраивает операторы SQL.

Трудно переоценить важность регулярного резервного копирования MySQL. Без последней резервной копии ваш бизнес и его сайты находятся на расстоянии аппаратного сбоя от катастрофы. С cPanel & WHM вы и ваши пользователи получаете выгоду от простого процесса резервного копирования и восстановления в два клика.

Как всегда, если у вас есть отзывы или комментарии, дайте нам знать. Мы здесь, чтобы помочь всем, что в наших силах. Вы найдете нас в Discord, на форумах cPanel и Reddit.

Правильный подход к резервному копированию базы данных — Redmondmag.com

Джои на SQL Server

Правильный подход к резервному копированию базы данных

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

  • Джои Д’Антони
  • 19.05.2021

Как администратор базы данных (DBA) ваша основная задача — гарантировать, что вы не потеряете данные в случае системного сбоя, ошибки пользователя или атаки вредоносного ПО.

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

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

Каков наилучший подход?
Если я реализую решение для резервного копирования для SQL Server (или любой другой базы данных) в среде с нуля, мой основной подход состоит в использовании собственных резервных копий базы данных, выполняющих резервное копирование в какой-либо файловый ресурс.Если сервер работает в Azure или имеет низкую сетевую задержку, я сделаю резервную копию в хранилище Azure.

Я использую Microsoft MVP Ola Hallengren’s Maintenance Solution, который представляет собой набор сценариев T-SQL и заданий агента SQL Server с открытым исходным кодом, для выполнения этих резервных копий и других операций по обслуживанию. Халленгрен — MVP платформы данных Microsoft из Швеции. Его код существует уже много лет и работает в большинстве случаев. SQL Server включает встроенные планы обслуживания, которые также могут выполнять резервное копирование и другие задачи обслуживания системы, но я предпочитаю код Халленгрена, поскольку он более прозрачен в том, как он регистрирует выполнение.Решение Hallengren также взаимодействует с инструментами резервного копирования ряда сторонних поставщиков резервного копирования SQL Server.

Существует множество вариантов резервного копирования SQL Server, которые вы можете настроить в соответствии со своими потребностями. Однако есть пара, которую я почти всегда устанавливаю. Первый — это разделение резервной копии на несколько файлов. Это может значительно повысить производительность резервного копирования за счет эффективного распараллеливания процесса резервного копирования.Обычно я рекомендую использовать меньшее значение количества ядер ЦП на вашем сервере или восемь файлов. Если у вас особенно большой сервер и большие базы данных, вы можете увидеть преимущества, превышающие восемь файлов, но преимущества ограничены. Использование нескольких файлов особенно важно при резервном копировании в Azure, поскольку размер одного файла в хранилище BLOB-объектов ограничен 50 МБ / с, что значительно ограничивает вашу пропускную способность.

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

Где должны храниться эти резервные копии?
Я упомянул две цели выше: файловый ресурс и хранилище BLOB-объектов Azure. Однако давайте немного углубимся в базовое хранилище.

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

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

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

Как насчет решений резервного копирования на основе инфраструктуры?
Программное обеспечение и услуги резервного копирования занимают большое место в индустрии программного обеспечения. И поставщики хранилищ, и поставщики программного обеспечения для резервного копирования имеют комплексные решения для резервного копирования, которые будут выполнять резервное копирование ваших виртуальных машин (ВМ), хранилищ и баз данных.

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

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

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


Об авторе

Джозеф Д’Антони — архитектор и MVP по SQL Server с более чем десятилетним опытом работы в компаниях из списка Fortune 500 и небольших фирмах.В настоящее время он является главным консультантом Denny Cherry and Associates Consulting. Он имеет степень бакалавра компьютерных информационных систем в Технологическом университете Луизианы и степень магистра делового администрирования в Университете штата Северная Каролина. Джоуи является со-президентом Филадельфийской группы пользователей SQL Server. Он часто выступает на мероприятиях PASS Summit, TechEd, Code Camps и SQLSaturday.

.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *