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

Содержание

SQL Backup for SQL Server

Получите полный контроль над созданием резервных копий SQL Server!

  • Быстрое развертывание политик резервного копирования
  • Сжатие и шифрование резервных копий
  • Поддержка популярных облачных хранилищ
  • Непрерывный мониторинг журналов резервного копирования

 

Скачать бесплатную пробную версию

Ключевые особенности

Быстрый бэкап и восстановление

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

Сжатие и шифрование файлов

Экономьте место на диске с помощью эффективного режима сжатия, многопоточного выполнения операций и шифрования с использованием алгоритмов AES, DES, Blowfish.

Облачные сервисы

Сохраняйте резервные копии в удаленные хранилища. Реализована поддержка Amazon S3, FTP (SSL), SFTP (SSH), сетевых папок Windows (CIFS), Microsoft Azure, Google Drive, Dropbox.

Набор сервисных задач для регулярного обслуживания БД

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

Автоматизация выполнения сервисных задач

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

Быстрое развертывание

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

Скриншоты продукта

Просмотр состояния серверов и баз данных

Просмотр текущей активности сервера

Поддержка облачных хранилищ

Создание шаблонов политик

Просмотр истории политик

Анализ состояния политик и решение проблем

Характеристики продукта

  • Многопоточное выполнение операций резервного копирования для увеличения быстродействия
  • Мгновенная выгрузка резервных копий в несколько облачных хранилищ
  • Резервное копирование нескольких баз данных в один файл
  • Массовое восстановление: аварийное восстановление нескольких баз данных
  • Поддержка облачных хранилищ (FTP (SSL), SFTP (SSH), Сетевые папки Windows (CIFS), Dropbox), Google Drive, Amazon S3, Microsoft Azure
  • Поддержка SQL Server Failover Cluster
  • Возможность выполнения 11 типов сервисных задач, включая резервное копирование, реиндексацию, обновление статистики и др.
  • Доставка баз данных между SQL серверами по расписанию
  • Простая организация процесса доставки журналов с помощью удобного мастера
  • Интеллектуальное восстановление
  • Быстрое развертывание задач обслуживания на нескольких серверах
  • Централизованное наблюдение за состоянием политик на множестве серверов
  • Возможность получать уведомления по электронной почте
  • Составление отчетов по результатам обслуживания баз данных

При покупке Вы получите также:

  • БЕСПЛАТНАЯ подписка на 1 год Сопровождения!
  • БЕСПЛАТНЫЕ Минорные и Мажорные обновления в период действия Обслуживания!
  • БЕСПЛАТНАЯ неограниченная техническая поддержка в период действия Сопровождения!
  • Разумные расценки на продление Сопровождения – всего от 35% в год!
  • Скидки при покупке двух и более лицензий одного продукта
  • Скидки на покупку сопутствующих продуктов
  • Гарантия возврата денег в течение 30 дней

SQL Backup for SQL Server

Начните работу с SQL Backup for SQL Server

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

Скачать бесплатную пробную версию

Есть вопросы?

Если вам требуется какая-либо помощь, если у вас есть вопросы по нашим продуктам или по вариантам приобретения, просто свяжитесь с нами.

Сопутствующие продукты

Упростите и автоматизируйте процесс администрирования SQL Server

Скачать
Подробнее

Комплексное решение для администрирования и разработки баз данных SQL Server

Скачать
Подробнее

Упростите и автоматизируйте процесс разработки баз данных SQL Server

Скачать
Подробнее

Резервное копирование MS SQL


Дата публикации: 27 декабря 2018 г.


* * *


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


В рамках планирования аварийного восстановления MS SQL особый интерес представляют два параметра: допустимое время восстановления (recovery time objective — RTO) и допустимая точка восстановления (recovery point objective — RPO).


RPO иными словами, это период времени с момента последнего резервного копирования до момента инцидента, за который будет потерян не критичный объём данных (информации). RTO — это допустимое время, за которое необходимо восстановить работоспособность сервиса/системы с момента инцидента. Оба параметра имеют переменное значение и зависят от требований к той или иной системе. Поэтому для выполнения, установленных RPO и RTO необходимо иметь соответствующий план резервного копирования. На примере, проведём анализ возможных аварийных инцидентов и попробуем выделить точки отказа нашего SQL сервера и способы их решения:


  • аппаратный сбой, физический выход сервера из строя: диски, CPU, системная плата, блок питания и т.д.


  • программный сбой: операционная система, база данных


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


* * *


HIGH AVAILABILITY MS SQL


При высоких требованиях к RPO и RTO (секунды/минуты) единственным решением для обеспечения отказоустойчивости MS SQL является организация технологии высокой доступности сервера (High Availability):


  • Встроенными средствами MS SQL и ОС Windows Server мы можем достичь высокой доступности (High Availability) за счет реализации отказоустойчивого кластера Windows Server Failover Cluster (WSFC) в том числе и с применением технологии AlwaysOn. Отказоустойчивый кластер состоит как минимум из двух узлов/серверов. При сбое активного сервера, происходит аварийное переключение на другой доступный сервер, он становится активным. При этом все службы, которые размещались на сервере автоматически или вручную переносятся на другой доступный узел.


  • В случаи, с виртуальной машиной MS SQL высокую доступность можно обеспечить c помощь средств виртуализации VMware HA-cluster или Hyper-V High Availability. В этом случае при выходе из строя физического сервера, позволяет автоматически запустить виртуальную машину на другом сервере кластера.


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


Преимущества High Availability MS SQL:


  • мгновенное переключение с ноды на ноду, без простоя


  • без зависимости от физических серверов


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


Недостатки High Availability MS SQL:


  • реализации требует дополнительной инфраструктуры и ресурсов


  • высокая стоимость решения по лицензиям и оборудованию


  • более сложное и высоквалифицированное обслуживание


* * *


BACKUP MS SQL


В случаях, когда требования к RTO и RPO не высокие и потребность в High Availability (кластеризации) отсутствует, для обеспечения отказоустойчивости баз данных MS SQL на физическом или виртуальном сервере необходимым условием является наличие резервной копии. Для этого можно задействовать встроенные функции SQL Server или использовать отдельные специализированные системы, поддерживающие различные способы резервного копирования MS SQL, например:


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


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


* * *


Регламент backup MS SQL


  • Резервные копии должны находиться на разных физических носителях с исходными файлами базы данных


  • Используйте тестовый сервер (песочница) для проверки процедуры восстановления резервных копий


  • Выполняйте ежедневное полное резервное копирование


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


  • Как можно чаще выполняйте резервное копирование журналов транзакций. Журналы транзакций содержат все последние действия, произошедшие в базе данных. Журналы можно использовать для восстановления базы данных на определенный момент времени, и это является самым большим преимуществом. Резервные копии журнала транзакций могут выполняться во время работы системы. Если частота новых данных, создаваемых в вашей базе данных, очень высока, то можно делать резервные копии журнала транзакций каждые 10 минут, в то время как для других баз данных, которые менее активны, такое резервное копирование может выполняться каждые 30 или 60 минут


  • Делайте резервное копирование системных баз данных MS SQL: server, master , model и msdb . Эти базы данных абсолютно необходимы, так как содержат конфигурацию системы, а также информацию о задании SQL Server, которую необходимо будет восстановить в случае полного восстановления системы


* * *


НАСТРОЙКА РЕЗЕРВНОГО КОПИРОВАНИЯ MS SQL С ПОМОЩЬЮ BACKUP EXEC


Скачать


Руководство администратора Backup Exec


Backup Exec предлагает три метода резервного копирования MS SQL: Full, Differential и Full Copy-only. Метод Full выполняет полное резервное копирование всей базы данных, а Differential выполняет резервное копирование только измененых блоков в базе данных с момента последнего полного резервного копирования. Метод Full Copy-only идентичен полному резервному копированию, но только он не влияет на последующие задания дифференциального резервного копирования.


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


Затем, в настройках параметров (опции) выбрать тип задания (сначала настроить Full потом Differential backup).


Далее, для настройки Full backup на вкладке Microsoft SQL выбрать один из двух методов резервного копирования: Full или Full Copy.


В Backup Exec есть очень важная и полезная функция «Проверка целостности базы до и после выполнения резервного копирования» (Consistency check before/after backup), имеется на выбор четыре варианта:


  • не проводить проверку


  • полная проверка, без учёта индексов


  • полная проверка с учётом индексов


  • только физическая проверка


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


Для настройки differential backup необходимо (аналогично job full backup) сначала добавить новое задание Job Differential, а затем на вкладке Microsoft SQL выбрать один из методов резервного копирования.


В данном списке в первую очередь интересует «Differential — Backup up database changes since the last full» (создание дифференциальной резервной копии на основании полной). Так же возможен вариант создания дифференциальной резервной копии (на уровне блоков) с последующей конвертацией в виртуальную машину «Differential (block-level) — Backup up database changes since the last full – use with convert to virtual machine job».


Еще одним важным параметром является «Log — Back up and truncate transaction log» для резервного копирования журнала транзакций MS SQL.


Мы рассмотрели основные моменты резервного копирования MS SQL. Обращаем внимание, что резервное копирование является частью общего плана аварийного восстановления (DRP), поэтому, перед планированием резервного копирования, необходимо провести полный анализ систем и инфраструктуры, для обеспечения RPO и RTO. А если есть возможность выполнить планирование DRP при разработке системы, это поможет исключить многие проблемы и, возможно, удешевит эксплуатацию системы.


Используемая в статье информация взята из официальных источников:
Отказоустойчивая кластеризация Windows Server с SQL Server
Руководство администратора Backup Exec

SQL Backup Master — Бесплатное программное обеспечение для резервного копирования SQL за пределами площадки

Простое, надежное, БЕСПЛАТНОЕ резервное копирование базы данных SQL за пределами площадки для всех.

Загрузить сейчасОбновите до версии Pro

ПРОСТОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗ ДАННЫХ SQL SERVER ВНЕ САЙТА

SQL Backup Master создает резервные копии ваших баз данных SQL Server в любом количестве популярных облачных сервисов хранения, таких как
Dropbox, OneDrive, Amazon S3, Microsoft Azure, Box, Google Cloud Storage, Backblaze B2, Google Drive, IDrive e2 и другие.
Он также может создавать резервные копии баз данных на FTP-сервере, в папке, сетевом сервере или на устройстве хранения.

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

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

Узнайте о новых функциях в SQL Backup Master 6

SQL Backup Master 6.3 расширяет поддержку S3

ВОЗМОЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ РЕЗЕРВНОГО ОБЕСПЕЧЕНИЯ SQL

  • Поддерживает полное, дифференциальное резервное копирование и резервное копирование журнала транзакций.

  • Простое, но мощное планирование заданий резервного копирования

  • Отправляйте уведомления о заданиях резервного копирования по электронной почте, оповещениям на рабочем столе и через веб-перехватчики.

  • Резервное копирование в локальные папки, сетевые папки или подключенные устройства хранения

  • Резервное копирование на FTP-серверы с первоклассной поддержкой FTP, SFTP и FTPS

  • Резервное копирование в Dropbox, Google Drive, Box, Amazon S3, OneDrive и Azure

SQL Backup Master — одно из самых популярных в мире решений для резервного копирования SQL.

Попробуйте сегодня и убедитесь, почему так много пользователей зависят от SQL Backup Master.

  • Сжимайте и шифруйте ценные резервные копии баз данных

  • Запускается автоматически в фоновом режиме как системная служба

  • Мощный, интуитивно понятный журнал резервного копирования и просмотр журнала

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

  • Автоматически очищать резервные копии старше указанного периода времени

  • Выполнение пользовательских SQL и пакетных сценариев до и после резервного копирования

БЕСПЛАТНАЯ базовая версия! Загрузите сейчас и начните немедленно!

Загрузить сейчасОбновить до Pro

БОЛЕЕ 60 000 КЛИЕНТОВ ДОВЕРЯЮТ ПРОГРАММЕ KEY METRIC

О резервных копиях Cloud SQL | Облачный SQL для MySQL

MySQL
| PostgreSQL
| SQL Server

На этой странице описывается, как работают резервные копии вашего экземпляра Cloud SQL.

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

Общие сведения о том, как восстановить данные в экземпляр из резервной копии, см.
Обзор восстановления экземпляра.

Какие резервные копии обеспечивают

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

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

Сколько стоят резервные копии

По умолчанию для каждого экземпляра Cloud SQL сохраняет семь автоматизированных
резервных копий, в дополнение к резервным копиям по требованию. Ты можешь
настроить количество автоматических резервных копий для хранения (от 1
до 365). Мы
взимайте более низкую плату за хранилище резервных копий, чем за другие типы инстансов.

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

См. страницу цен
Чтобы получить больше информации.

Резервные копии по сравнению с экспортом

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

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

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

О размере резервной копии

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

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

Cloud SQL выполняет два типа резервного копирования:

  • Резервное копирование по запросу
  • Автоматическое резервное копирование

Резервное копирование по запросу

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

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

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

Автоматическое резервное копирование выполняется ежедневно в течение 4-часового окна резервного копирования.
резервное копирование начинается во время окна резервного копирования. По возможности запланируйте резервное копирование
когда ваш экземпляр имеет наименьшую активность.

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

Место хранения резервных копий

Местоположения резервных копий включают:

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

Места хранения резервных копий по умолчанию

Если вы не укажете место хранения, ваши резервные копии будут храниться в мультирегионе,
географически ближе всего к местоположению вашего экземпляра Cloud SQL. Например, если ваш
Экземпляр Cloud SQL находится в us-central1 , ваши резервные копии хранятся в
us мультирегион по умолчанию. Однако расположение по умолчанию, например
australia-southeast1 находится за пределами нескольких регионов. Ближайший мультирегион
азия .

Примечание. При восстановлении данных из резервной копии восстанавливайте их в экземпляр в
доступный регион. Чтобы просмотреть список всех резервных копий экземпляра в регионе,
происходит сбой, используйте подстановочный знак — с список резервных копий gcloud sql --instance
или API backupRuns. list . Дополнительные сведения см. в разделе Просмотр списка резервных копий во время простоя.
Затем вы можете восстановить данные из резервной копии на новый или существующий экземпляр в регионе, в котором нет сбоя.

Пользовательские хранилища резервных копий

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

При выборе пользовательского расположения для резервного копирования учитывайте следующее:

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

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

Дополнительные сведения о настройке местоположений для резервных копий и просмотре местоположений резервных копий, созданных для экземпляра, см. в разделах Установка пользовательского расположения для резервных копий и Просмотр расположений резервных копий.

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

Автоматическое резервное копирование и сохранение журнала транзакций

Автоматическое резервное копирование используется для восстановления
экземпляр Cloud SQL. Сочетание автоматизированного резервного копирования и транзакций
журналы используются для выполнения восстановления на определенный момент времени.

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

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

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

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

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

Журналы транзакций старше последней резервной копии автоматически удаляются.

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

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

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

См. Настройка автоматического хранения резервных копий.

См. раздел Настройка хранения журнала транзакций.

Можно ли экспортировать резервную копию?

Нет, вы не можете экспортировать резервную копию. Вы можете экспортировать только данные экземпляра. Видеть
Экспорт данных из Cloud SQL.

О специальном пользователе резервного копирования

Cloud SQL создает специального пользователя базы данных cloudsqladmin для каждого
instance и генерирует для него уникальный пароль для конкретного экземпляра.
Cloud SQL входит в систему как пользователь cloudsqladmin для автоматического резервного копирования.

Как резервное копирование влияет на операции экземпляра

Для экземпляров MySQL флаг FLUSH TABLES WITH READ LOCK не установлен.
используется для резервного копирования. Это означает, что записи и другие операции не затрагиваются.
операциями резервного копирования.

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

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

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

Ограничения скорости резервного копирования

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

Давайте посмотрим, как работает Cloud SQL.
ограничение скорости резервного копирования.

Cloud SQL использует токены из корзины, чтобы определить, сколько операций резервного копирования
доступны в любой момент времени. У каждого экземпляра есть ведро. Максимум
пять токенов в корзине, которые можно использовать для операций резервного копирования. Каждые 10
минут в корзину добавляется новый токен. Если ведро заполнено, токен переполняется.

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

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

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

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

После удаления экземпляра Cloud SQL удаляет все резервные копии. Предотвращать
случайное удаление экземпляров, Cloud SQL сохраняет
резервные копии на четыре дня. Чтобы восстановить удаленный экземпляр, обратитесь
Служба поддержки клиентов Google Cloud в течение четырех дней.

Cloud SQL сохраняет как минимум одну последнюю действующую ежедневную резервную копию каждого
активный экземпляр. В результате, если хороших резервных копий нет, вы можете
используйте ежедневное резервное копирование для восстановления вашего экземпляра, связавшись с
Служба поддержки клиентов Google Cloud.

Поиск и устранение неисправностей

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

Запустить
список операций gcloud sql команда для вывода списка всех
операций для данного экземпляра Cloud SQL.

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

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

  • cloudsql.googlapis.com/mysql-general.log
  • облакоsql.googleapis.com/mysql.err
  • Если журналы облачного аудита включены и
    у вас есть необходимые разрешения для их просмотра,
    cloudaudit.googleapis.com/activity также может быть доступен.
После удаления экземпляра вы не можете создать его резервную копию.

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

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

Автоматическое резервное копирование зависает на много часов и не может быть отменено. Резервное копирование может занять много времени в зависимости от размера базы данных.

Если вам действительно нужно отменить операцию, вы можете попросить

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

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

Создайте пользователей базы данных перед восстановлением дампа SQL.

Вы хотите увеличить количество дней, в течение которых вы можете сохранять автоматическое
резервное копирование от семи до 30 дней или дольше.		 Вы можете
настроить количество сохраняемых автоматических резервных копий,
от 1 до 365. Автоматические резервные копии удаляются
регулярно в зависимости от настроенного значения хранения. К сожалению, это означает, что
видимые в настоящее время резервные копии — это единственные автоматические резервные копии, из которых можно восстановить.

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

Imacros | Все права защищены © 2021