Бэкап сайта: Бэкап сайта: что такое и как грамотно его сделать

Бэкап сайта: что такое и как грамотно его сделать

1. Что такое Backup
2. Зачем он нужен?
3. Как его сделать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем делать бэкап сайта? — польза резервного копирования сайта

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

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

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

Перед внесением изменений

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

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

При доработках на сайте

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

Для защиты сайта

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

Бекап на хостинге SpaceWeb

Как сделать бэкап сайта? На хостинге SpaceWeb резервные копии файлов и баз данных MySQL создаются автоматически каждый день

.

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

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

Как сделать бэкап сайта – правила резервного копирования. 💕

19 ноября 2018

1 610

Время чтения ≈ 8 минут

Содержание

1. Вступление
2. Частые ошибки при резервном копировании
3. Инструменты резервного копирования
4. Что нужно знать про ежедневный бэкап
5. Заключение
6. Чеклист по созданию бэкапа

Резервная копия – вопрос выживания

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

Несмотря на продвинутые технологии защиты, это сокровище подвергается ежедневной опасности. Перебои в работе сервера, программные сбои, проблемы с оборудованием, хакерские атаки. Единственным надёжным способом обезопасить свой ресурс остаётся резервное копирование сайта (aka backup или бэкап).

Как это: потерять результаты работы над сайтом за год, месяц, неделю..?

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

Частые ошибки при резервном копировании

Делать резервные копии только вручную

Ручной бэкап сайта хорош для новичков. Серьёзному проекту этот способ вряд ли подойдёт – слишком медленно и не эффективно.

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

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

Может быть смешно только, если случилось не с тобой

Даже в разгар эпохи доступного хостинга находятся ещё веб-мастера и владельцы блогов, которые делают резервное копирование только 1-2 в месяц.

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

Не составлять расписания бэкапов

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

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

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

Делать выборочное резервное копирование

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

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

Не проверять результаты бэкапа

Крылатая латинская фраза «Помни о смерти» применима и к сайтам

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

Наладить мониторинг бэкапов поможет тестирование результатов. Как минимум, нужно периодически тестировать резервные копии на целостность (media test) и восстановление (recovery test). Оптимальное решение – использовать сервисы, которые не только могут восстановить сайт из бэкапа, но и способны автоматически проверить результаты.

Делать только одну копию

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

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

Хранить бэкап и сайт на одном сервере

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

Сочетание нескольких способов хранения бэкапов даёт гарантию безопасности данных.

Для хранения резервных копий сайта можно порекомендовать популярные облачные сервисы, вроде Dropbox, Microsoft OneDrive или Google Drive. Профессиональные веб-мастера советуют совмещать «облачное» хранение с бэкапами на съёмных физических носителях.

Инструменты создания бэкапов

• Панель управления хостинга
• Менеджер файлов хостинга
• Плагины резервного копирования для CMS
• FTP-клиент FileZilla
• Скрипт phpMyAdmin
• Файловый менеджер Total Commander
• Сервис удалённого хранения файлов Amazon S3 (Simple Storage Service)

Перечисленные инструменты – бесплатные или с рабочей триальной версией, которую можно не обновлять до полной. Есть и платные онлайн-сервисы (Codeguard, WSR, BackupGuard, WP Time Capsule), с помощью которых удобно настраивать автоматический бэкап.

Что узнать про бэкап у хостера

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

• Сколько храниться. Средний срок хранения информации после полного бэкапа сайта – 24 часа. Это сильно снижает возможность маневра, если критический сбой или ошибка была замечена спустя несколько дней. Идеальный вариант – обговорить с хостером возможность хранения «ежедневной» копии от 3 до 7 дней.
• Место сохранения. Держать резервные копии на том же сервере, что и сам ресурс – частая и непростительная ошибка. После очередной хакерской атаки можно разом лишиться всех данных.
• Когда можно использовать. Внимательно читайте договор с провайдером. Получить право на восстановление информации клиент имеет только в том случае, если проблема возникла по вине хостера. Если «злодеи» похитили у владельца ресурса пароли и стёрли всю информацию, провайдер имеет законное право отказать в бэкапе. Хорошая новость – подобные трудные моменты обычно легко урегулируются на уровне личного общения с администраторами хостинга.

Вывод: на провайдера надейся, а сам не плошай

Многие хостинг-провайдеры включают автоматическое резервное копирование в список базовых услуг. Но периодичность и качество бэкапов не позволяют исключить проблемы на 100%. В Сети найдётся немало историй о рухнувших серверах, похоронивших под обломками многомесячную работу по созданию контента. Или о нанятых конкурентами хакерах, которые одним махом обрушили кропотливо выстроенный сетевой бизнес.

Британский хостер 123 Reg оказался в центре скандала из-за потери данных пользователей

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

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

7 шагов для надёжного резервирования

1. Выберите способ создания резервных копий. Встроенные инструменты панели управления хостинга, программы, плагины CMS или онлайн-сервисы.
2. Составьте расписание и настройте автоматизацию. Лучший вариант – ежедневно с хранением каждой копии 5-7 дней.
3. Делайте бэкап перед каждым изменением функционала сайта. При добавлении новых компонентов, установке плагинов, версий CMS, смене тем оформления.
4. Дублируйте создание резервных копий. Наряду с бэкапами, создаваемыми хостером, нужно делать копии на собственных носителях.
5. Убедитесь, что бэкап отрабатывается корректно. Нет ли сбоев в планировщике или уведомлений об ошибках в панели управления хостингом.
6. Проведите тестирование резервной копии. Запустите пробное восстановление данных на копии текущего сервера. Частота – раз в неделю или месяц, в зависимости от обновления данных и уровня безопасности.
7. Периодически проверяйте свободное место для хранения бэкапов.

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

Оцените материал:

[Всего голосов: 2    Средний: 4/5]

Всё пропало! Или нет? Часть I. Как сделать резервную копию сайта

Что такое бэкап сайта и зачем он нужен

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

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

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

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

Словарь терминов

Составили для вас список терминов, которые будут встречаться в статье.

FTP (File Transfer Protocol) — это протокол, который используется для передачи файлов.

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

FTP-сервер — это любой сервер, который поддерживает FTP. 

FTP-клиент — это программа для простого доступа к удалённому FTP-серверу. Может работать в режиме текстовой консоли, пересылая команды пользователя и файлы. Или же отображать файлы на удалённом сервере, как если бы они были на вашем компьютере. А может выполнять и оба сценария одновременно.

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

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

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

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

Что важно учесть при резервном копировании

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

По FTP чаще всего происходит заражение сайта — работайте в FTP-клиенте на защищённом от вирусов компьютере.

Подготовьте место для бэкапа файлов и дампа базы данных сайта — на компьютере, удалённом FTP-cервере или облачном хранилище (Dropbox, Google Drive, Облако Mail.ru и другие). Весить они будут почти столько же, сколько сам сайт (чуть меньше, но всё же).

Как сделать резервное копирование

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

Резервное копирование файлов сайта

Можно сделать через панель управления хостингом, FTP-клиент FileZilla и SSH-доступ.

Через панель управления хостингом

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

Как сделать бэкап сайта на WordPress: 2 способа резервного копирования

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

О резервном копировании встроенными средствами cPanel можно прочесть в разделе «Мастер резервного копирования» статьи «Раздел Файлы в cPanel».

В данной статье мы рассмотрим детальнее резервное копирование с помощью плагина All-in-One WP Migration.

Как восстановить сайт из резервной копии WordPress с помощью плагина All-in-One WP Migration

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

Мы рассмотрим один из самых популярных плагинов — All-in-One WP Migration. Он очень удобен для переноса сайта, создания регулярных резервных копий и изменения доменного имени сайта.

Сначала нужно установить плагин All-in-One WP Migration в консоли сайта:

1. Для этого перейдите в Плагины – Добавить новый и введите название плагина в поиске.

2. Нажмите Установить и Активировать:

После активации плагин появится в меню административной панели.

У плагина есть три функции:

Рассмотрим каждую отдельно по порядку.

Экспорт

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

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

Вам предложат сохранить файл с расширением .wpress в одной из директорий вашего компьютера:

Резервные копии

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

Импорт

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

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

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

3. Перейдите в раздел Настройки – Постоянные ссылки административной панели WordPress и сохраните изменения.

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

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

Помогла ли эта статья решить вашу проблему?

Ваш ответ поможет улучшить статьи в будущем.

Бэкап сайта. Резервное копирование сайта на хостинге RedDoc

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

Кому полезна услуга

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

Какие данные сохраняются

• Файлы сайта
• Базы данных сайта
• Настройки аккаунта (SSL-сертификаты, почта)
• Личные файлы, которые хранятся на хостинге.

Как это работает

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

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

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

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

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

Устроено это очень просто: на вашем основном сервере создается небольшая порция архивной копии (100-200 Мб) и отправляется на FTP-сервер. После успешной передачи данных порция удаляется с основного сервера, и запускается процесс создания новой порции. И так до тех пор, пока все данные не будут переданы на сервер резервного копирования.

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

Подытожим:

1. Данные сайта хранятся на основном сервере, а архивные копии — на другом
2. Для процесса резервного копирования необходимо столько места на основном сервере, сколько весит максимальный дамп базы данных
3. Резервное копирование проходит в фоновом режиме, незаметным для вас и ваших клиентов
4. Архивные копии делятся на два вида — полные и дифференциальные
5. На FTP-сервере хранится минимум 1 полная копия и 6 дифференциальных
6. Можно восстановить как весь сайт, так и отдельный файл или базу данных.

Хранение архивных копий на отдельном сервере позволяет сохранить и восстановить данные в случае неисправности основного сервера. А создание дифференциальных копий — ускорить процесс резервного копирования и существенно сэкономить место на FTP-сервере.

Удобное восстановление данных

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

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

Отличие стандартных средств 1С-Битрикс от FTP-бэкапа на тарифах RED

В «1С-Битрикс: Управление сайтом» есть стандартные способы хранения резервных копий — локально на сервере или в облаке 1С-Битрикс. Важно понимать, чем отличается услуга FTP-бэкапа от резервного копирования 1С-Битрикс, и использовать преимущества обеих систем для построения многоуровневой защиты данных вашего сайта.

Таблица сравнения

	Резервное копирование от 1С-Битрикс	FTP-бэкап от Reddock
Объем предоставляемого места для хранения резервных копий	До 20 ГБ с возможностью платного расширения блоками по 200 ГБ	В 1,5 раза больше, чем места на диске по вашему тарифу хостинга
Скорость создания резервной копии	Низкая	Средняя
Количество резервных копий	Ограничено предоставленным объемом облака 1С-Битрикс	1 полная резервная копия и 6 дифференциальных
Отказоустойчивость процесса резервного копирования	Низкая	Высокая
Надежность хранения данных	Высокая	Средняя
Возможность частичного восстановления данных	Нет	Да, до файла или базы данных
Расходование лишнего места на хостинге	Да, необходимо место для временного хранения полного размера резервной копии	Необходимо место только для временного хранения дампа базы данных

Резервное копирование от 1С-Битрикс: локальное хранение резервных копий

Локальное хранение копий 1С-Битрикс подразумевает под собой размещение резервных копий на хостинге внутри корневой папки вашего сайта (/bitrix/backup/). Отсюда вытекают две неприятные ситуации — расходуется лишнее место на хостинге и появляется риск выхода сайта из строя.

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

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

Резервное копирование от 1С-Битрикс: облачное хранение резервных копий

Резервное копирование в облако 1С-Битрикс состоит из двух этапов: создание полной резервной копии сайта на хостинг и передача архивных копий на хранение в облако 1С-Битрикс. С созданием локальной копии мы уже разобрались, теперь рассмотрим процесс передачи резервной копии в облако.

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

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

Скорость создания резервной копии тоже очень важна. Передача резервных копий в облако 1С-Битрикс медленная, так как процесс происходит по сети Интернет. У крупных проектов на создание и передачу бэкапов может уйти до 24 часов. Это ставит под вопрос целесообразность использования такого способа резервного копирования, ведь за сутки данные могут полностью обновится, и резервная копия станет не актуальной. А в случае неполадок или временного отсутствия связи с Интернетом резервная копия не будет передана вовсе и останется лежать на вашем сервере.

Резервное копирование от Reddock: хранение резервных копий на FTP-сервере

Резервное копирование на FTP сервер исключает недостатки стандартных средств 1С-Битрикс. Его отличительные особенности:

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

Рекомендуем использовать FTP-бэкап в сочетании со стандартными способами резервного копирования 1С-Битрикс. Так вы повысите эффективность защиты ваших данных и сможете восстановить нужную информацию в экстренном случае.

Бэкап сайта Joomla и его структура

Бэкап сайта (backup, резервная копия) — это, как правило, архивированная копия сайта (zip архив), который содержит в себе весь сайт. Бэкап сайта делается для того, что в случае каких-либо непредвиденных проблем, повреждений сайта, хакерских атак, неправильно установленных модулей или изменений, повлекших неработоспособность сайта, вы всегда могли восстановить свой сайт из резервной копии. Поэтому делать бэкапы очень важно и, просто-напросто, жизненно необходимо.
Каждый владелец сайта рано или поздно сталкивается с необходимостью создания бэкапа своего сайта. Если вы еще никогда не делали бэкапов своего сайта — обязательно прочитайте эту статью и сделайте свою резервную копию на всякий случай. Существует огромное количество случаев, когда люди не делали бэкапов, а потом просто теряли свои сайты, пострадавшие от сбоев, вирусов и хакерских атак.
Существует 2 способа создания резервных копий сайта:

1) ручной способ

2) с помощью расширений

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

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

Чтобы окончательно не запутаться и понять разницу, приведём пример.
Допустим, вы устанавливаете на сайт расширение (плагин, например). В данном случае в корень сайта загружаются все файлы, например, html, css, js и другие. Все это находится в корневом каталоге.
А когда вы настраиваете данное расширение, например, если это новостной модуль, вводите информацию о том, какие категории вы хотите вывести в новости на главную страницу, то данные параметры вносятся в базу данных.

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

Теперь, когда вы рассмотрели 2 основные составляющие сайта Joomla, давайте поговорим о бэкапах.

1 способ: Создание копии вручную

Немного нудный способ, однако многие вебмастеры любят данный способ за однозначность и надежность. По сути, для этого вам не понадобится ничего, кроме стандартных средств хостинга.
Для начала — откройте панель управления вашим хостингом и откройте файловый менеджер (если у вас есть прямой доступ к cPanel  или ISPManager, то найдите менеджер файлов прямо в нем).
Откройте каталог сайта (как правило называется site или www).
Выделите все файлы, находящиеся в данном каталоге.
Добавьте все содержимое в архив (обычно с помощью кнопки над содержимым).
Бэкап корня готов! Теперь вы можете скачать архив. Теперь осталось сделать копию БД.
Для этого откройте панель управления базами данных и phpmyadmin (в cPanel и ISPManager — сразу phpmyadmin).
Выберите в списке слева вашу базу данных.
Откройте вкладку экспорт и экспортируйте базу данных.
Готово! База данных сохранится на ваш компьютер.
Итак, после использования первого способа вы получите отдельный архив из директории сайта и отдельный SQL-файл с БД.
Не самый удобный способ, но знать его необходимо, на случай, если вдруг не будет возможности воспользоваться плагином. К слову, сделав такой бэкап вы можете запросто перенести сайт на другой хостинг!

2 способ: использование плагинов (Akeeba Backup)

Для решения очень большого круга проблем, в настоящий момент, можно использовать плагины (но взломанные платные плагины могут создать только больше проблем!).
Самым известным, популярным и скачиваемым плагином для создания backup на Joomla является Akeeba Backup. Существует 2 его версии: платная и бесплатная. Отличаются они набором функций и возможностей. Но самое главное то, что обе версии выполняют свою прямую функцию! Скачать расширение можно на этой странице.
Итак, чтобы сделать резервную копию Joomla в Akeeba следуйте следующим пунктам:
Для начала скачайте и установите расширение.
После — откройте его, зайдя в Компоненты — Akeeba Backup

Нажмите кнопку — Начать резервное копирование

Подождите, пока закончится копирование

Бэкап готов! Найти его можно или в управлении компонентом, либо на вкладке вашсайт.ру/administrator/components/com/akeeba/backup.

 

Конечно же, предварительно нужно настроить плагин. Но это другая история 🙂 Об этом мы еще расскажем!

 

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

Резервное копирование и восстановление файлов или папок с помощью инструмента Site Backup Pro

---

---

Обзор

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

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

Возможности Site Backup Pro

Автоматическое резервное копирование	Создает ежедневную резервную копию веб-сайта для предотвращения потери данных.
Ежедневно, еженедельно и ежемесячно	Благодаря долгосрочным, средним и краткосрочным архивам резервных копий у вас больше шансов найти нужную версию.
Восстановление в один клик	Автоматическое восстановление файлов путем замены текущих файлов версиями из резервных копий.
Быстро и просто	Всего три шага для восстановления файлов.
Восстановление баз данных и таблиц	Простое восстановление баз данных MySQL.Вы также можете выбрать отдельные таблицы для восстановления.
Восстановление одного или нескольких файлов	Быстро восстановить только нужный файл или файлы.
Загрузить .zip-архивы файлов	Загрузка .zip позволяет клиентам получить мгновенный автономный доступ к своим файлам.

Как получить доступ к Site Backup Pro и управлять им

Доступ к Site Backup Pro

Для резервного копирования или восстановления файлов вашего веб-сайта вы можете использовать инструмент Site Backup Pro , расположенный в категории File Management вашей cPanel.

1. Войдите в свою панель управления Bluehost.
2. В разделе Files откройте инструмент Site Backup Pro .
   

Управление резервным копированием сайта Pro Выберите, хотите ли вы: Обзор, , Загрузить, или Восстановить файлы из резервной копии.

• При загрузке резервной копии появится запрос на выбор даты. Используйте раскрывающееся меню, чтобы выбрать подходящую дату резервного копирования, которое вы хотите использовать.Затем выберите тип сжатого файла, который вы хотите загрузить. Это может быть файл .tar или .zip, затем нажмите «Загрузить сейчас».
  Примечание: Если вы не уверены, какой формат загружать, выберите .zip , поскольку все современные операционные системы могут открывать файл .zip.
• При просмотре файлов в правом верхнем углу есть раскрывающееся меню, которое позволяет выбрать дату резервного копирования.
  Примечание: Эта функция доступна только при покупке Site Backup Pro.
• При восстановлении файлов всплывающее меню попросит вас выбрать дату резервного копирования для восстановления.
  Примечание: Это тот же процесс, что и для параметра «Домашний каталог» в Site Backup Pro.

Резервное копирование и восстановление сайта — Bluehost

Резервное копирование и восстановление сайта — Bluehost

Защитите свой сайт с помощью

автоматических резервных копий онлайн!

• Автоматически восстанавливает потерянные файлы
• Обеспечивает контроль версий
• Загружает файлы в.zip архив

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

Инструмент

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

Быстро и просто

Загрузить потерянные файлы с помощью инструмента резервного копирования и восстановления сайта очень просто — всего три шага, чтобы восстановление ваших файлов!

Ежедневно, еженедельно и ежемесячно

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

Восстановление одного или нескольких файлов

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

Восстановление в один клик

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

Скачать .ZIP Архив файлов

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

Восстановление баз данных и таблиц!

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

Инструмент резервного копирования веб-сайтов

В этом руководстве рассматриваются следующие темы:

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

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

Обратите внимание, что помимо этих автоматических резервных копий системы, выполняемых SiteGround, вы можете создать до 5 резервных копий по запросу с нашими планами GrowBig и GoGeek или приобрести отдельные резервные копии с помощью StartUp.

Как создать резервную копию и восстановить свой сайт

Чтобы создать новую резервную копию, просто введите имя резервной копии в поле Backu p Имя в разделе Create & Restore . Нажмите Создать , и через несколько минут резервная копия вашего сайта будет готова.

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

Как восстановить определенные данные

Если вам нужно восстановить только ваши файлы, базы данных или электронную почту, перейдите к Управление резервными копиями > Действия Меню (рядом с нужной резервной копией). Затем выберите тип данных, которые вы хотите восстановить, и выполните следующие соответствующие шаги.

Подробнее:

Как просмотреть историю восстановления

Вы можете просмотреть историю своих восстановлений за последние 14 дней в Инструменты сайта> Безопасность> Резервные копии> История восстановления . В таблице вы можете найти дополнительную информацию о типе восстановления, дате восстановления и т. Д.

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

Резервное копирование сайтов — Документация по продукту Acquia

Облачная платформа предоставляет множество различных вариантов резервного копирования. Для информацию о резервных копиях в Cloud Platform см. в разделе Резервное копирование приложения. В дополнение к этим вариантам резервного копирования Site Factory размещенные веб-сайты также могут использовать полное резервное копирование сайта.

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

Вы можете создавать и загружать резервные копии веб-сайтов с помощью Консоль управления фабрикой сайтов и восстановление веб-сайта из резервной копии. Вы также можете использовать REST API Site Factory для создания, составления списка и удаления резервных копий, а также для восстановления веб-сайта из резервной копии.

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

Site Factory хранит файлы резервных копий в каталоге g / files . Ты можешь доступ к этому месту, чтобы удалить ненужные файлы.

Например,

 [адрес электронной почты защищен]: / mnt / files / testacsf01live / sites / g / files $ du -sh mxsain126 /
17 г mxsain126 /
 

Разрешения

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

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

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

Чтобы создать резервную копию веб-сайта, выполните следующие действия:

1. Войдите в Интерфейс Site Factory.

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

3. Щелкните Резервное копирование сайта .

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

5. Щелкните Резервное копирование .

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

Просмотр доступных резервных копий

Вы можете просмотреть и загрузить резервные копии своего веб-сайта на странице «Резервные копии сайта»:

1. Войти в Интерфейс Site Factory.
2. В административном меню вверху страницы щелкните Сайты .
3. В нижней части левого столбца щелкните Все резервные копии моего сайта .

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

Чтобы восстановить резервную копию, укажите нужную резервную копию и в Действиях столбце, щелкните Восстановить в строке резервной копии:

Примечание

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

Скачивание файлов резервных копий

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

Восстановление из файла резервной копии

Важно

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

Для получения информации об использовании файла резервной копии для восстановления веб-сайта см. Восстановление сайта из резервной копии.

Что такое автономное резервное копирование?

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

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

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

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

Историческое правило резервного копирования «3-2-1» гласит, что организация должна иметь три копии данных на двух разных носителях, причем одна копия носителя должна быть размещена за пределами площадки. Внешнее резервное копирование важно в случае аварии, атаки программы-вымогателя или другого инцидента в главном центре обработки данных. Когда происходит такой инцидент, организация восстанавливается, извлекая резервные копии данных из облака или с ленточных картриджей. Хотя локальное резервное копирование обеспечивает более быстрый доступ, резервное копирование за пределами площадки служит важной защитной сеткой.

Облако — это основная цель для малого и среднего бизнеса, позволяющая создавать резервные копии данных более дешевым и простым способом. SMB также может использовать внешний жесткий диск для резервного копирования вне офиса. Хотя резервное копирование на жесткий диск проще, он не такой портативный и прочный, как лента. Лента обычно больше подходит для предприятий и отраслей, таких как СМИ, развлечения и науки о жизни, которые должны хранить большие объемы данных. Кроме того, у малого и среднего бизнеса обычно меньше ресурсов, чем у предприятия, для перемещения лент за пределы площадки.

Ключи к удаленному резервному копированию

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

Также должен быть реализован план хранения для удаления данных резервных копий, которые больше не нужны. Например, цена на Amazon Glacier, один из самых дешевых облачных решений и распространенную платформу архивирования, начиналась с 0 долларов.004 за гигабайт в месяц по состоянию на сентябрь 2018 года. Хотя это может показаться дешевым, хранение 100 ТБ данных за пределами площадки будет стоить почти 5000 долларов в год. Другие расходы, связанные с облачным резервным копированием, также могут быть высокими. Такие затраты могут включать извлечение данных и стоимость получения данных из облака.

Стоимость резервного копирования на ленту со временем также увеличивается из-за стоимости дополнительных носителей и внешнего хранилища. Эти расходы различаются в зависимости от региона, но стандартный тариф Amazon на получение данных из хранилища Glacier составляет 0 долларов США.01 на гигабайт. Эта стоимость утроится для ускоренных запросов.

Стоимость передачи данных из Glacier зависит от региона, объема данных и от того, куда данные передаются. Как правило, передача данных в облачный сервис Amazon обходится дешевле, чем в Интернет. В любом случае затраты на передачу данных могут быть значительными. Amazon позволяет бесплатно передавать один гигабайт данных из Glacier в Интернет в восточном регионе США. После этого стоимость 0 $.09 за гигабайт, в месяц до 10 ТБ данных; дополнительные передачи данных оплачиваются по сниженному тарифу. Это означает, что передача 10 ТБ данных из хранилища Glacier в Интернет будет стоить более 900 долларов.

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

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

Ленточная безопасность в основном упоминается в терминах физической. Чтобы ограничить вероятность кражи лент, организация должна отправить их, как только они закончат писать на них, а затем обеспечить безопасность удаленного хранилища. В соглашении об уровне обслуживания (SLA) будет указано, кто имеет доступ к лентам и сколько времени должно занять время восстановления. Как и в случае с облаком, важно шифрование.Linear Tape-Open 8, выпущенный в конце 2017 года, поддерживает 256-битный расширенный стандарт шифрования, а также возможность «писать один раз, читать много».

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

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

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

За пределами площадки по сравнению с выездом на место

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

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

Важность внешних резервных копий

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

Поставщики программного обеспечения для резервного копирования

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

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

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

Общие особенности удаленного резервного копирования

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

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

Как работает удаленное резервное копирование

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

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

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

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

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

Гибридное резервное копирование

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

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

Выбор варианта резервного копирования

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

Внешние провайдеры резервного копирования

Бесчисленное количество поставщиков выступают в роли внешних поставщиков резервного копирования. Эти поставщики обычно попадают в одну из трех категорий:

• Гипермасштабирующие устройства : Это крупные универсальные поставщики общедоступных облаков, такие как Microsoft Azure, AWS и Google Cloud Platform. Они предоставляют облачное хранилище резервных копий, но также предлагают множество других услуг.
• Традиционные поставщики резервного копирования : Эти поставщики могут создавать свои собственные частные облачные среды, которые предназначены исключительно для выполнения задач по размещению данных резервного копирования.
• Съемный носитель : Третья категория поставщиков внешних резервных копий — это те, которые предназначены для безопасного хранения съемных носителей, таких как резервные ленты. Эти поставщики транспортируют носители в и из безопасного средства резервного копирования и гарантируют, что ленты хранятся в надлежащих условиях, гарантируя при этом безопасность данных.

сайтов резервного копирования — Configuration Manager

• 08.10.2020
• 15 минут на чтение

В этой статье

Применимо к: Configuration Manager (текущая ветвь)

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

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

Предупреждение

Для восстановления сайта Configuration Manager поддерживаются два метода резервного копирования:

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

Рекомендации перед созданием резервной копии

• Если вы используете группу доступности SQL Server AlwaysOn для размещения базы данных сайта: измените планы резервного копирования и восстановления, как описано в разделе Подготовка к использованию группы доступности.

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

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

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

Использование Data Protection Manager для резервного копирования базы данных сайта

Для резервного копирования базы данных сайта Configuration Manager можно использовать System Center Data Protection Manager (DPM).

Создайте новую группу защиты в DPM для компьютера с базой данных сайта. На странице Выбор членов группы мастера создания новой группы защиты выберите службу SMS Writer из списка источников данных. Затем выберите базу данных сайта в качестве подходящего участника. Дополнительные сведения об использовании DPM см. В библиотеке документации Data Protection Manager.

Важно

Configuration Manager не поддерживает резервное копирование DPM для экземпляра отказоустойчивого кластера SQL Server AlwaysOn, который использует именованный экземпляр.Он поддерживает резервное копирование DPM на экземпляре отказоустойчивого кластера, который использует экземпляр SQL Server по умолчанию.

После восстановления базы данных сайта следуйте инструкциям по установке, чтобы восстановить сайт. Чтобы использовать базу данных сайта, резервную копию которой вы создали с помощью Data Protection Manager, выберите вариант восстановления Использовать базу данных сайта, которая была восстановлена ​​вручную .

Задача обслуживания резервного копирования

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

• Работает по расписанию
• Резервное копирование базы данных сайта
• Резервное копирование определенных разделов реестра
• Резервное копирование определенных папок и файлов
• Резервное копирование компакт-диска Последняя папка

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

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

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

При запуске службы резервного копирования Configuration Manager она следует инструкциям, определенным в файле управления резервным копированием: \ Inboxes \ Smsbkup.box \ Smsbkup.ctl . Вы можете изменить файл управления резервным копированием, чтобы изменить поведение службы резервного копирования.

Примечание

Изменения Smsbkup.ctl вступят в силу после перезапуска службы SMS_SITE_VSS_WRITER на сервере сайта.

Информация о состоянии резервного копирования сайта записывается в Smsbkup.log файл. Этот файл создается в папке назначения, которую вы указываете в свойствах задачи обслуживания «Резервное копирование сервера сайта».

Включение задачи обслуживания резервного копирования сайта

1. В консоли Configuration Manager перейдите в рабочую область Administration , разверните Site Configuration и выберите узел Sites .

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

3. Выберите Задачи обслуживания сайта на ленте.

4. Выберите задачу Backup Site Server и выберите Edit .

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

   Важно

   Чтобы предотвратить подделку файлов резервных копий, храните файлы в безопасном месте.Самый безопасный путь для резервного копирования — на локальный диск, поэтому вы можете установить для папки разрешения NTFS-файла. Configuration Manager не шифрует данные резервной копии, хранящиеся в резервном пути.

   • Локальный диск на сервере сайта для данных сайта и базы данных : указывает, что задача сохраняет файлы резервных копий для сайта и базы данных сайта по указанному пути на локальном диске сервера сайта. Создайте локальную папку перед запуском задачи резервного копирования. Учетная запись локальной системы на сервере сайта должна иметь разрешения на запись файлов NTFS в локальную папку для резервной копии сервера сайта.Учетная запись локальной системы на компьютере, на котором выполняется SQL Server, должна иметь разрешения Write NTFS для папки для резервной копии базы данных сайта.

   • Сетевой путь (имя UNC) для данных сайта и базы данных : указывает, что задача сохраняет файлы резервных копий для сайта и базы данных сайта по указанному сетевому пути. Создайте общий ресурс перед запуском задачи резервного копирования. Учетная запись компьютера на сервере сайта должна иметь Запись NTFS и разрешить общий доступ к общей сетевой папке.Если SQL Server установлен на другом компьютере, учетная запись компьютера SQL Server должна иметь такие же разрешения.

   • Локальные диски на сервере сайта и SQL Server : указывает, что задача сохраняет файлы резервных копий для сайта по указанному пути на локальном диске сервера сайта. Задача сохраняет файлы резервных копий для базы данных сайта по указанному пути на локальном диске сервера базы данных сайта. Перед запуском задачи резервного копирования создайте локальные папки.Учетная запись компьютера на сервере сайта должна иметь разрешения Write NTFS для папки, которую вы создаете на сервере сайта. Учетная запись компьютера SQL Server должна иметь разрешения Write NTFS для папки, которую вы создаете на сервере базы данных сайта. Этот параметр доступен только в том случае, если база данных сайта не установлена ​​на сервере сайта.

   Примечание

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

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

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

   Когда вы запускаете консоль Configuration Manager на том же сервере сайта, который вы настраиваете для резервного копирования, задача резервного копирования использует местное время для расписания.Когда вы запускаете консоль Configuration Manager с другого компьютера, задача резервного копирования использует всемирное координированное время (UTC) для расписания.

7. Выберите, следует ли создавать предупреждение в случае сбоя задачи резервного копирования сайта. Если этот параметр выбран, Configuration Manager создает критическое предупреждение о сбое резервного копирования. Вы можете просмотреть эти предупреждения в узле Alerts рабочего пространства Monitoring .

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

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

• Перейдите к узлу Состояние компонента рабочего пространства Мониторинг . Просмотрите сообщения о состоянии для SMS_SITE_BACKUP . Когда резервное копирование сайта завершится успешно, вы увидите сообщение с идентификатором 5035 . Это сообщение означает, что резервное копирование сайта выполнено без ошибок.

• Когда вы настраиваете задачу резервного копирования для создания предупреждения в случае сбоя, ищите предупреждения о сбое резервного копирования в узле Alerts рабочего пространства Monitoring .

• Откройте проводник Windows на сервере сайта и перейдите в папку \ Logs . Просмотрите Smsbkup.log на предмет предупреждений и ошибок. Когда резервное копирование сайта завершается успешно, в журнале отображается Резервное копирование завершено с идентификатором сообщения STATMSG: ID = 5035 .

  Подсказка

  В случае сбоя задачи обслуживания резервного копирования перезапустите задачу резервного копирования, остановив и перезапустив службу Windows SMS_SITE_BACKUP .

Архивировать снимок резервной копии

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

Хранить несколько архивов моментального снимка резервной копии по следующим причинам:

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

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

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

Используйте файл AfterBackup.bat

После успешного резервного копирования сайта задача резервного копирования автоматически пытается запустить сценарий с именем AfterBackup.bat . Вручную создайте AfterBackup.bat на сервере сайта в папке \ Inboxes \ Smsbkup.box . Если файл AfterBackup.bat существует в правильной папке, он автоматически запускается после завершения задачи резервного копирования.

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

Если файл AfterBackup.bat отсутствует, задача резервного копирования пропускает его, не влияя на операцию резервного копирования. Чтобы убедиться, что задача резервного копирования успешно выполнила этот сценарий, перейдите к узлу Component Status в рабочем пространстве Monitoring и просмотрите сообщения о состоянии для SMS_SITE_BACKUP . Когда задача успешно запускает командный файл AfterBackup.bat, вы увидите сообщение с идентификатором 5040 .

Подсказка

Для архивирования файлов резервных копий сервера сайта с помощью AfterBackup.bat, вы должны использовать инструмент команды копирования в пакетном файле. Одним из таких инструментов является Robocopy в Windows Server. Например, создайте файл AfterBackup.bat с помощью следующей команды: Robocopy E: \ ConfigMgr_Backup \\ ServerName \ ShareName \ ConfigMgr_Backup / MIR

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

Дополнительные задачи резервного копирования

Задача обслуживания «Резервное копирование сервера сайта» предоставляет моментальный снимок резервной копии файлов сервера сайта и базы данных сайта.Есть и другие элементы, для которых не созданы резервные копии, которые вы должны учитывать при создании стратегии резервного копирования. Используйте эти разделы, чтобы помочь вам завершить стратегию резервного копирования Configuration Manager.

Резервное копирование пользовательских отчетов

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

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

Важно

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

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

Резервное копирование файлов содержимого

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

• Перед распространением содержимого в точки распространения необходимо восстановить библиотеку содержимого. Когда вы запускаете распространение контента, Configuration Manager копирует файлы из библиотеки контента сервера сайта в точки распространения.Для получения дополнительной информации см. Библиотека содержимого.

• Перед обновлением содержимого в точках распространения необходимо восстановить исходные файлы пакета. Когда вы запускаете обновление содержимого, Configuration Manager копирует новые или измененные файлы из источника пакета в библиотеку содержимого. Затем он копирует файлы в связанные точки распространения. Выполните следующий запрос SQL к базе данных сайта, чтобы найти расположение источника пакета для всех пакетов и приложений: SELECT * FROM v_Package .Вы можете определить сайт источника пакета, посмотрев на первые три символа идентификатора пакета. Например, если идентификатор пакета — CEN00001, код исходного сайта — CEN. При восстановлении исходных файлов пакета их необходимо восстановить в то же место, где они находились до сбоя.

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

Резервное копирование пользовательских обновлений программного обеспечения

System Center Updates Publisher — это автономный инструмент, который позволяет управлять пользовательскими обновлениями программного обеспечения.Updates Publisher использует локальную базу данных для своего репозитория обновлений программного обеспечения. При использовании Updates Publisher для управления пользовательскими обновлениями программного обеспечения определите, следует ли включать базу данных Updates Publisher в свой план резервного копирования. Дополнительные сведения см. В разделе «Издатель обновлений System Center».

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

Резервное копирование базы данных Updates Publisher

1. На компьютере, на котором запущен Updates Publisher, перейдите к файлу базы данных Updates Publisher Scupdb.sdf в % ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ% \ AppData \ Local \ Microsoft \ System Center Updates Publisher 2011 \ 5.00.1727.0000 \ . Для каждого пользователя, запускающего Updates Publisher, существует отдельный файл базы данных.

2. Скопируйте файл базы данных в место назначения резервного копирования. Например, если место назначения резервной копии — E: \ ConfigMgr_Backup , вы можете скопировать файл базы данных Updates Publisher в E: \ ConfigMgr_Backup \ SCUP .

   Подсказка

   Если на компьютере имеется более одного файла базы данных, подумайте о том, чтобы сохранить файл во вложенной папке, которая указывает профиль пользователя, связанный с файлом базы данных.Например, у вас может быть один файл базы данных в E: \ ConfigMgr_Backup \ SCUP \ User1 и другой файл базы данных в E: \ ConfigMgr_Backup \ SCUP \ User2 .

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

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

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

1. В консоли Configuration Manager перейдите в рабочую область Администрирование , разверните Конфигурация сайта и выберите узел Серверы и роли системы сайта .

2. Выберите систему сайта, в которой размещается роль миграции состояния.Затем выберите точку миграции состояния на панели Роли системы сайта .

3. Выберите Свойства на ленте.

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

Об услуге SMS Writer

Модуль записи SMS — это служба, которая взаимодействует со службой теневого копирования томов Windows (VSS) во время процесса резервного копирования.Для успешного завершения резервного копирования сайта Configuration Manager должна быть запущена служба SMS Writer.

Процесс

1. Модуль записи SMS регистрируется в службе VSS и привязывается к ее интерфейсам и событиям.

2. Когда VSS транслирует события или отправляет определенные уведомления в модуль записи SMS, модуль записи SMS отвечает на уведомление и предпринимает соответствующие действия.

3. Модуль записи SMS читает файл управления резервным копированием smsbkup.ctl , расположенный в папке \ inboxes \ smsbkup.box , определяет файлы и данные для резервного копирования.

4. SMS Writer создает метаданные, которые состоят из различных компонентов, включая определенные данные из раздела и подразделов реестра SMS.

   1. Он отправляет метаданные в VSS по запросу.

   2. VSS затем отправляет метаданные запрашивающему приложению Configuration Manager Backup Manager.

5. Backup Manager выбирает данные для резервного копирования и отправляет эти данные в модуль записи SMS через VSS.

6. Модуль записи SMS предпринимает соответствующие шаги для подготовки к резервному копированию.

7. Позже, когда VSS будет готов сделать снимок:

   1. Отправляет событие

   2. Модуль записи SMS останавливает все службы Configuration Manager

   3. Он гарантирует, что действия Configuration Manager будут заблокированы на время создания моментального снимка.

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

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

Идентификатор писателя

Идентификатор записи для модуля записи SMS: 03ba67dd-dc6d-4729-a038-251f7018463b .

Разрешения

Служба SMS Writer должна работать под учетной записью локальной системы.

Служба теневого копирования тома

VSS — это набор COM API, реализующий структуру, позволяющую выполнять резервное копирование томов, пока приложения в системе продолжают запись на тома. VSS обеспечивает согласованный интерфейс, который позволяет координировать действия между пользовательскими приложениями, обновляющими данные на диске (служба SMS Writer), и приложениями, выполняющими резервное копирование приложений (служба Backup Manager). Дополнительные сведения см. В разделе Служба теневого копирования томов.

Следующие шаги

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

Как создать резервную копию вашего веб-сайта

Есть два варианта резервного копирования вашего веб-сайта GreenGeeks.

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

Вариант 1. Используйте cPanel Backup Tool

Если размер вашей учетной записи превышает 10 ГБ, этот вариант будет недоступен.См. Раздел о создании собственных резервных копий.

Войдите в GreenGeeks и перейдите в cPanel, нажав кнопку «cPanel» в разделе «Быстрый вход на сервер».

Щелкните ссылку «Резервное копирование» в разделе «Файлы» cPanel.

Нажмите кнопку «Домашний каталог», чтобы загрузить резервную копию домашнего каталога вашего веб-сайта.

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

Если вам нужна резервная копия всей учетной записи cPanel, нажмите кнопку «Загрузить полную резервную копию учетной записи».

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

Резервное копирование cPanel отключено для учетных записей размером более 10 ГБ . Для учетных записей размером более 10 ГБ следуйте приведенным ниже инструкциям по резервному копированию.В качестве альтернативы вы можете запросить, чтобы GreenGeeks сгенерировал полную резервную копию cPanel. За резервное копирование, выполняемое GreenGeeks, взимается комиссия в размере 5 долларов США (за cPanel).

Вариант 2: Создание резервных копий своего собственного веб-сайта

Если вы используете систему управления контентом, такую ​​как Drupal, WordPress, или любой веб-сайт, на котором работает база данных, вам необходимо создать резервную копию базы данных, а также файлы веб-сайта. Если у вас простой веб-сайт, вы просто создаете резервные копии файлов веб-сайта.

Резервное копирование файлов веб-сайтов

Мы рекомендуем использовать программу FTP, такую ​​как FileZilla, для резервного копирования ваших файлов.Скопируйте весь каталог / public_html из своей учетной записи веб-хостинга на локальный компьютер. Если ваша электронная почта также размещена в GreenGeeks, вы можете сделать резервную копию, загрузив каталог / mail.

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

Войдите в GreenGeeks и перейдите в cPanel, нажав кнопку «Вход в cPanel» в разделе «Быстрый вход на сервер».