No Image

Что такое бэкап базы данных

СОДЕРЖАНИЕ
0 просмотров
10 марта 2020

Резервное копирование (англ. backup copy ) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Содержание

Наименование операций [ править | править код ]

  • Резервное копирование данных (резервное дублирование данных) — процесс создания копии данных.
  • Восстановление данных — процесс восстановления в оригинальном месте.

Цель [ править | править код ]

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

Кроме этого, решается проблема передачи данных и работы с общими документами.

Требования к системе резервного копирования [ править | править код ]

  • Надёжность хранения информации — обеспечивается применением отказоустойчивого оборудования систем хранения, дублированием информации и заменой утерянной копии другой в случае уничтожения одной из копий (в том числе как часть отказоустойчивости).
  • Многоплатформенность — полноценное функционирование системы резервного копирования в гетерогенной сети предполагает, что её серверная часть будет работать в различных операционных средах и поддерживать клиенты на самых разных аппаратно-программных платформах.
  • Простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).
  • Быстрое внедрение — простая установка и настройка программ, быстрое обучение пользователей.

Ключевыми параметрами резервного копирования являются:

  • RPO — Recovery Point Objective;
  • RTO — Recovery Time Objective.

RPO определяет точку отката — момент времени в прошлом, на который будут восстановлены данные, а RTO определяет время, необходимое для восстановления из резервной копии.

Виды резервного копирования [ править | править код ]

Существует несколько видов резервного копирования [1] [2] :

Полное резервное копирование (Full backup) [ править | править код ]

Дифференциальное резервное копирование (Differential backup) [ править | править код ]

Инкрементное резервное копирование (Incremental backup) [ править | править код ]

Клонирование [ править | править код ]

Резервное копирование в виде образа [ править | править код ]

Резервное копирование в режиме реального времени [ править | править код ]

Холодное резервирование [ править | править код ]

Горячее резервирование [ править | править код ]

Схемы ротации [ править | править код ]

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

Одноразовое копирование [ править | править код ]

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

Простая ротация [ править | править код ]

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

«Дед, отец, сын» [ править | править код ]

Данная схема имеет иерархическую структуру и предполагает использование комплекта из трёх наборов носителей. Раз в неделю делается полная копия дисков компьютера («отец»), ежедневно же проводится инкрементальное (или дифференциальное) копирование («сын»). Дополнительно раз в месяц проводится ещё одно полное копирование («дед»). Состав ежедневного и еженедельного набора постоянен. Таким образом, по сравнению с простой ротацией в архиве содержатся только ежемесячные копии плюс последние еженедельные и ежедневные копии. Недостаток данной схемы состоит в том, что в архив попадают только данные, имевшиеся на конец месяца, а также в износе носителей.

«Ханойская башня» [ править | править код ]

Схема призвана устранить некоторые из недостатков схемы простой ротации и ротации «Дед, отец, сын». Схема построена на применении нескольких наборов носителей. Каждый набор предназначен для недельного копирования, как в схеме простой ротации, но без изъятия полных копий. Иными словами, отдельный набор включает носитель с полной недельной копией и носители с ежедневными инкрементальными (дифференциальными) копиями. Специфическая проблема схемы «ханойская башня» — её более высокая сложность, чем у других схем.

«10 наборов» [ править | править код ]

Данная схема рассчитана на десять наборов носителей. Период из сорока недель делится на десять циклов. В течение цикла за каждым набором закреплён один день недели. По прошествии четырёхнедельного цикла номер набора сдвигается на один день. Иными словами, если в первом цикле за понедельник отвечал набор номер 1, а за вторник — номер 2, то во втором цикле за понедельник отвечает набор номер 2, а за вторник — номер 3. Такая схема позволяет равномерно распределить нагрузку, а следовательно, и износ между всеми носителями.

Схемы «Ханойская башня» [ источник не указан 2919 дней ] и «10 наборов» используются нечасто, так как многие системы резервного копирования их не поддерживают.

Хранение резервной копии [ править | править код ]

  • Лента стримера — запись резервных данных на магнитную ленту стримера;
  • «Облачный» бэкап — запись резервных данных по «облачной» технологии через онлайн-службы специальных провайдеров;
  • DVD или CD — запись резервных данных на компактные диски;
  • HDD — запись резервных данных на жёсткий диск компьютера;
  • LAN — запись резервных данных на любую машину внутри локальной сети;
  • FTP — запись резервных данных на FTP-серверы;
  • USB — запись резервных данных на любое USB-совместимое устройство (такое, как флэш-карта или внешний жёсткий диск).
Читайте также:  Asus bw 16d1ht blk g as

Причины утери информации [ править | править код ]

Эксплуатационные поломки носителей информации [ править | править код ]

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

Решение: хранить всю информацию (каждый файл) минимум в двух экземплярах (причём каждый экземпляр на своём носителе данных). Для этого применяются:

Описание: шторм, землетрясение, кража, пожар, прорыв водопровода — всё это может привести к потере всех носителей данных, расположенных на определённой территории.

Борьба: единственный способ защиты от стихийных бедствий — держать часть резервных копий в другом помещении. В частности, помогает резервное копирование через сеть на компьютер, расположенный достаточно далеко (или в облачное хранилище данных).

Вредоносные программы [ править | править код ]

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

  • Установка антивирусных программ на рабочие станции. Простейшие антивирусные меры — отключение автозагрузки, изоляция локальной сети от Интернета, и т. д.
  • Обеспечение централизованного обновления: первая копия антивируса получает обновления прямо из Интернета, а другие копии настроены на папку, куда первая загружает обновления; также можно настроить прокси-сервер таким образом, чтобы обновления кэшировались (это всё меры для уменьшения трафика).
  • Иметь копии в таком месте, до которого вирус не доберётся — выделенный сервер или съёмные носители.
  • Если копирование идёт на сервер: обеспечить защиту сервера от вирусов (либо установить антивирус, либо использовать ОС, для которой вероятность заражения мала). Хранить версии достаточной давности, чтобы существовала копия, не контактировавшая с заражённым компьютером.
  • Если копирование идёт на съёмные носители: часть носителей хранить (без дописывания на них) достаточно долго, чтобы существовала копия, не контактировавшая с заражённым компьютером.
  • Использование носителей с однократной записью: CD-R, DVD-R, BD-R. Их объём недостаточен для серьёзных применений.

Человеческий фактор [ править | править код ]

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

  • Тщательно расставить права на все ресурсы, чтобы другие пользователи не могли модифицировать чужие файлы. Исключение делается для системного администратора, который должен обладать всеми правами на всё, чтобы быть способным исправить ошибки пользователей, программ и т. д.
  • Построить работающую систему резервного копирования — систему, которой люди реально пользуются и которая достаточно устойчива к ошибкам оператора. Если пользователь не пользуется системой резервного копирования, вся ответственность за сохранность ложится на него.
  • Хранить версии достаточной давности, чтобы при обнаружении испорченных данных файл можно было восстановить.
  • Перед переустановкой ОС следует обязательно копировать всё содержимое раздела, на которой будет установлена ОС, на сервер, на другой раздел или на CD/DVD.
  • Оперативно обновлять ПО, которое заподозрено в потере данных.

Затруднения при резервном копировании [ править | править код ]

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

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

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

Search

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

Введение

Любому системному администратору иили программисту известна аксиома "бэкапов мало не бывает". Среди администраторов также ходит слух "системные администраторы делятся на тех кто делает быкапы и на тех кто их будет делать". Могу сказать, что постоянная тяга делать бэкапы перед любым изменением в системе, иногда даже и без изменений, например проснувшись посреди ночи в холодном поту, признак того что it-специалист достиг первой ступени просветления. Достигнуть можно двумя путями: простой — поверить что без этого никак и сразу начать их делать, посложней — наступить на избитые грабли, надеяться на надежное оборудование и ответственных пользователей, ни то ни другое не дает и 90%, что и приведет вас сначала к феерическому провалу. затем наступит просветление — бэкапить и еще раз бэкапить, днем и ночью.

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

Зачем нужен бэкап

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

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

Читайте также:  Email адреса для рассылки бесплатно

В компаниях поменьше это обычные сервера, на которые добавили побольше дисков или один-два внешних HDD.

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

Как сделать бэкап

Первым делом смотрим где у нас хранятся данные. В случае с 1С это может быть два варианта:

  1. База файловая: данные хранятся в каталоге, нам нужен файл "*.1CD", который и содержит все данные.
  2. База серверная: база подключена через сервер 1С:Предприятия, сами данные хранятся на сервере СУБД (например MSSQL), файлы там тоже есть, но прямого доступа к ним мы не имеем.

В случае с MSSQL файл БД имеет расширение "*.mdf", а где хранится физически — можно узнать или специальной командой к серверу СУБД или в свойствах базы через консоль управления MSSQL, впрочем файлы СУБД нам и не нужны.

В зависимости от того какая база выбираем один из вариантов:

  1. Файловый вариант базы:
    • Вариант первый копирование файла БД:
      • Отключаем пользователей от базы (ночью можно и не отключать, также имейте ввиду что вариант не дает 100% рабочий бэкап, в случае когда с базой активно работают).
      • Копируем файл 1Cv8.1CD в любую папку
      • Сжимаем полученную копию архиватором
      • Перемещаем архив в хранилище бэкапов
      • Второй вариант через конфигуратор***:
        • Открываем базу в режиме "конфигуратор"
        • Выбираем в меню "Администрирование → Выгрузить информационную базу"
        • Перемещаем полученный файл *.dt в хранилище бэкапов. Файл dt уже сжат, поэтому архиватор тут не нужен.
        • Серверный вариант базы (сторонняя СУБД):
          • Специальной командой заставляем сервер СУБД "отдать" нам резервную копию файла БД в файл ХХХХХ.bak (стандартное расширение для бэкапов MSSQL "bak").
          • Сжимаем полученную копию архиватором. В новых версиях MSSQL, можно установить сжатие в момент создания файла bak (рекомендуется!), поэтому этот шаг можно пропустить.
          • Перемещаем архив в хранилище бэкапов. В новых верстиях MSSQL можно как место сохранения сразу указать сетевой каталог (рекомендуется!), поэтому этот шаг можно пропустить.

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

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

          Настройка бэкапов MSSQL

          • Открываем MSSQL Server Management Studio
          • Создаем новый план обслуживания → Правой на узел "Планы обслуживания" → Создать план
          • Добавляем графический блок резервного копирования (перетягиваем мышью "задачу" из панели слева)
          • Двойным кликом по рамке задачи открываем ее, заполняем свойства:
            1. Выбираем базы которые должны сохраняться
            2. Устанавливаем флаг сжатия баз. Внимание! Это значительно снижает трафик и занимаемое место!
            3. Выбираем каталог хранения бэкапов. Советую указывать сразу сетевой путь, хранилище бэкапов.
            4. По желанию настраиваем логирование процесса (кнопку см. на рис. выше), у меня лог сохраняется в папку, а также приходит письмо на эл. почту. Если надо отправлять письмо, то надо настроить соответствующий компонент и создать предварительно одного оператора.
            5. Готово. Проверку работоспособности выполняем так: правой на план → выполнить. После выполнения плана: смотрим лог выполнения, понятно файлы которые появились в хранилище, а также историю (правой на план → история).
            6. Проверка. Обязательно хотя бы один раз проверить работоспособность резервной копии. Как сделать: создаем новую пустую базу, правой на базу → . → восстановить, в качестве источника задаем сетевой путь к нашему файлу ХХХХХ.bak (можно скопировать путь из проводника), меняем в параметрах целевой файл (по умолчанию MSSQL попытается заменить рабочую базу) на файлы вашей новой копии — восстанавливаем в копию. На сервере 1С:Предприятие создаете новую базу "копия01", указываете, как источник, свою свежую копию на сервере SQL. Затем заходите в созданную копию через 1С, и проверяете что все на месте и работает.

            Настройка бэкапов в файловом варианте базы

            • Создаем скрипт который будет выполнять копирование файла 1CD, его сжатие и копирование архива в хранилище. Вот пример такого скрипта:
            • Все что нужно сделать — сохранить этот листинг в текстовый файл с расширением .vbs, заполнить переменные вверху скрипта своими данными (путь к логу, хранилищу . ), а также заполнить список баз, указав пути к своим базам. Далее добавить скрипт в планировщик windows, как правило еженощное выполнение.


            • Готово. Ждем первого запуска, для теста можно запустить задачу вручную — правой — выполнить.
            • Скрипт и вспомогательные утилиты можно скачать по ссылке.

            Заключение

            По MSSQL: в статье рассмотрен только вариант "полной" резервной копии. Для экономии места занимаемого бэкапами используют "разностные" копии (только изменения) и другие варианты, но в этом случае присутствуют свои заморочки с восстановлением — требуется не один файл бэкапа, а несколько.

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

            Читайте также:  Cro71 тульской области электронный журнал

            По файловому варианту БД: скрипт легко можно допилить на удаление старых копий, чтобы не держать заведомо устаревшие и потому бесполезные файлы. Можно добавить его же копию в другую задачу, но с периодичностью в месяц и указать другое хранилище, где будут храниться бэкапы раз в месяц. Наконец можно, вместо копирования и архивирования, указать команду запуска 1С и сохранения через конфигуратор бэкапа *.dt (см. запуск 1С в пакетном режиме).

            Что это такое бэкап сайта?

            Суть бэкапа сайта сводится к копированию баз данных, файлов сайта, почты, FTP-аккаунтов и множества других параметров хостинга. Проще говоря мы сохраняем весь сайт и его настройки в отдельном месте, и при необходимости можем вернуть сайт к той версии, которую сохранили. При этом может осуществляться копирование данных на текущий и бэкапный (дополнительный) сервер, располагающийся отдельно от серверов провайдера либо в другом дата-центре. Оно производится на случай, если что-то случится с сервером на котором хранится сайт. Таким образом в 2009 году после пожара в собственном дата-центре Hosting.ua удалось восстановить большую часть сайтов, копии которых хранились на других серверах.

            Для чего нужно резервное копирование сайта?

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

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

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

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

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

            Зачем сохранять к себе на компьютер?

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

            Как сделать бэкап сайта?

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

            С помощью хостинг-аккаунта

            Заходите в панель управления хостингом, и находите там раздел похожий на "Резервные копии", "Backup" или что-то подобное. Далее два пути:

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

            С помощью FTP-клиента и phpMyadmin

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

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

            Как вернуть сайт к сохраненной версии?

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

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

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

            Сколько бекапов нужно постоянно хранить?

            Это зависит от того, на сколько часто обновляется ваш сайт. Оптимальным для большинства сайтов можно назвать количество бекапов за год. Если делать их 1-2 раза в месяц, то получается 12-25 копий.

            Комментировать
            0 просмотров
            Комментариев нет, будьте первым кто его оставит

            Это интересно
            Adblock detector