Резервное
копирование сайта
Копия, из которой ни разу не восстанавливали, — это не копия. Расписание настраивается, восстановление проверяется на деле.
Цена работы2 200 ₽ / часминимум 1 час
Ответдо 15 минутв рабочее время
Начнём работусегодняили завтра
Доступыостаются у васничего не переносится
Что входит
- Копии файлов и базы по расписанию
- Хранение вне хостинга, чтобы не потерять вместе с сервером
- Глубина хранения: сколько дней хранится
- Проверка восстановления на тестовой копии
- Уведомления, если копия не сделалась
- Инструкция: как поднять сайт без нас
Цена работы
2 200 ₽ / час
Срок и объём часов называются до начала работ.
В абонплате
входит
На обслуживании эти работы идут в счёт пакета часов.
Причины и порядок резервного копирования сайта
Резервная копия сайта создаётся не для отчётности: от неё зависит, что реально можно вернуть после сбоя. Причины, из-за которых требуется бэкап, различаются. От них зависит, какая версия хранилища подходит сайту и как часто копию нужно делать. Разброс объясняется тем, какой тип сайта обслуживается и какая система хранения уже настроена.
Причины, из-за которых нужна резервная копия
Сбой сервера, ошибка при обновлении плагина, действие стороннего скрипта или обычная случайность — эти случаи ведут к одному результату. Часть данных сайта пропадает или искажается. База данных повреждается чаще файлов, потому что в неё непрерывно попадают изменения от заказов, комментариев и настроек. Без свежей копии восстановить прежнее состояние сайта вручную не получается.
Проблема иногда обнаруживается не сразу: сайт снаружи продолжает работать нормально, а часть информации в базе уже отсутствует. Чем позже создаётся копия после такого случая, тем меньше данных удаётся сохранить. По этой причине резервную копию делают регулярно, а не только перед крупными изменениями на сайте.
Создание копии вручную и по автоматической схеме
Копия сайта создаётся вручную через панель хостинга или систему управления, либо автоматически по заданному алгоритму. Ручной способ применяется, когда копию нужно создать разово — перед крупным изменением темы или структуры. Автоматическое создание работает без участия человека и снижает риск ошибки при выборе момента для копии.
Выбрать между вариантами помогает тип сайта: интернет-магазин с частыми заказами нуждается в более частом создании копий базы, а сайт-визитка — реже. Хранить копии рекомендуется отдельно от сервера, на облачном хранилище, чтобы сбой на диске сервера не затронул уже созданные версии.
Восстановление сайта из подходящей версии
Восстановить сайт можно из разных версий копии, и последняя по дате не всегда самая подходящая. Если ошибка появилась заметно раньше, она уже попала в резервный файл. Специалист сверяет момент создания копии с моментом появления проблемы на сайте и выбирает версию, где данные ещё не искажены.
После выбора версии база данных и файлы поднимаются на веб-сервере, а сайт осматривается на предмет пропавших изменений. Время восстановления зависит от объёма базы и числа файлов. Также важно, где размещён бэкап — на облачном хранилище или локальном диске сервера.
Когда резервное копирование не подойдёт как разовая мера
Разовая копия перед одним изменением не подойдёт, если сайт меняется часто: за короткий срок данные расходятся с последней сохранённой версией. В таком случае нужна система регулярного создания копий, а не единичный бэкап. Не подойдёт и хранение единственной копии на том же сервере, где работает сайт.
При сбое сервера недоступны становятся и актуальная версия, и резервная. Восстановить сайт в таком случае будет неоткуда, если резервная копия лежит там же. Что делать в такой ситуации, зависит от того, как часто сайт обновляется и меняется база данных.
Что владелец сайта получает по итогам создания копии
После настройки резервного копирования владелец сайта получает не только файл с копией. Отдельно видно, когда последняя копия была создана, и какой объём данных попадёт под восстановление. Фиксируется также, какая система применялась для создания копии и что делать, если автоматическое создание внезапно остановилось.
Стоимость и объём такой задачи зависят от размера сайта и числа файлов в базе. Также важно, сколько версий нужно хранить одновременно. На крупном сайте с интернет-магазином создание копии занимает больше места и требует более мощного хранилища, чем на небольшом сайте-визитке.
Состав и хранение резервной копии
Резервное копирование сайта не сводится к одному бэкапу на всякий случай. Значение имеет состав копии, инструмент, которым она создаётся, и место, куда она попадает после создания. Эти пункты определяют, насколько быстро проект восстанавливается после отказа системы.
Состав бэкапа
Бэкапы отличаются по составу: одни включают только данные, другие — весь проект. Полный бэкап сайта содержит структуру, оформление, настройки и содержимое проекта. Отдельно копируется база с заказами, комментариями и учётными записями клиентов. Такой состав позволяет восстановить сайт целиком, а не отдельные страницы. Резервная копия в этом смысле становится частью общей защиты проекта от потери данных.
Частичный бэкап затрагивает только выбранную часть проекта — например, новый раздел каталога или обновлённую тему. Такой вид копии занимает меньше места на ресурсе хранения и создаётся быстрее полного. Выбор между полным и частичным составом определяется тем, что именно меняется на сайте.
Инструмент для создания бэкапа
Резервную копию делает специальный инструмент — модуль хостинг-провайдера, плагин системы управления или отдельное решение для бэкапов. У каждого инструмента свой алгоритм. В одних инструментах достаточно нажать одну кнопку, чтобы копия создалась, другие действуют в фоне без участия человека. Провайдер хостинга обычно предлагает базовый инструмент, но его возможностей не всегда хватает интернет-магазину с большой базой. Модуль хостинг-провайдера обычно быстрее в настройке, чем сторонний сервис.
Не каждый инструмент даёт простой сценарий восстановления. Часть решений умеет сделать бэкап, но не поднимает сайт заново одним действием. При выборе решения смотрят, есть ли отдельная кнопка восстановления и совместим ли формат бэкапа с сервером. Клиенту стоит сравнить несколько бэкапов заранее, а не после отказа сайта.
Где хранить бэкап
Хранить резервную копию на одном сервере с сайтом рискованно. При отказе сервера пропадает и рабочий проект, и его бэкап. Отдельный ресурс — облачное хранилище или сервер другого провайдера — снижает эту угрозу. Клиент получает доступ к резервным копиям независимо от состояния основного хостинга.
На собственном компьютере бэкап держат редко. Устройство выходит из строя так же внезапно, как и сервер. Часть клиентов всё же хранит копию на компьютере вместо отдельного ресурса — и рискует ей в первую очередь. Новый бэкап при этом не должен вытеснять старые копии раньше нужного периода. Потеря даже одной резервной копии снижает шанс восстановить сайт в нужном состоянии.
Восстановление целиком или частично
Резервная копия позволяет восстановить сайт целиком либо поднять только повреждённый раздел — каталог, отдельную страницу или базу с заказами. Частичное восстановление занимает меньше времени и не трогает части проекта, которые остаются исправными. Выбор между целым восстановлением и частичным делает специалист после осмотра проекта.
Клиенту с интернет-магазином важно, что поднимается из копии первым — обычно база с текущими заказами. Оформление и структура каталога восстанавливаются следом, во вторую очередь. Такой порядок сокращает время простоя и возвращает основную функцию сайта раньше остального содержимого.
Когда отдельный бэкап не нужен
Разовый бэкап до одного изменения темы не имеет смысла, если на сайте уже настроено регулярное резервное копирование. Новая копия и так создаётся по общему порядку, без отдельного запроса. Отдельный инструмент для одного случая оправдан, только когда постоянной системы хранения на проекте ещё нет.
Не имеет смысла и отдельный бэкап для страницы-визитки без базы данных. Там достаточно сделать копию содержимого на любом ресурсе, без специального инструмента. Такая мера нужна там, где меняется база данных: интернет-магазин, каталог, личный кабинет клиента.
Экспорт данных, архив и заражение кода вирусом
У резервной копии есть практическая сторона. Кто получает данные сайта напрямую, что делает вирус с кодом сайта и когда услуга создания архива не нужна вовсе.
Права администратора и экспорт данных через phpMyAdmin
Права у учётных записей на сайте различаются. Основной пользователь панели видит вкладку phpMyAdmin и экспортирует таблицы данных прямо из панели. Такой экспорт даёт хороший результат, если нужен архив только с данными, без кода шаблонов и модулей. Специалист применяет phpMyAdmin, когда нужен точечный экспорт без общего образа сайта.
Основной администратор — не единственный, кто заходит в панель, но только у него есть права на экспорт всех таблиц данных. Дополнительные учётные записи открывают лишь общий раздел без вкладки phpMyAdmin. Раздать права всем сразу неудобно: слишком широкий экспорт повышает риск лишней ошибки.
Архив, образ сайта и ссылка для скачивания
Архив может включать образ сайта: код, шаблоны и данные в одном пакете. Готовый архив ложится по ссылке, которую администратор может скачать напрямую. Для надёжности сохраняются три предыдущих архива, а не только последний. Если нужен архив за конкретный месяц, дату экспорта можно уточнить заранее. Такой архив проще создавать регулярно, чем собирать сайт заново с нуля. Одного архива без описания даты хватает редко — быстрее находится тот, что подписан явно.
Свежий архив стоит держать под рукой, а не искать его в переписке, когда сайт уже недоступен. Ссылка на скачивание действует недолго, поэтому архив лучше сразу сохранить на своём носителе. Копию ссылки удобно дублировать в почту для быстрого поиска позже.
Заражение кода сайта вирусом
Вирус заражает код сайта иначе, чем неполадка на сервере. Заражённый код может попасть в архив ещё до того, как вирус себя проявит. Поэтому нужен архив, снятый до заражения, а не только последний по дате. Специалист проверяет код на признаки вируса, прежде чем применить архив и вернуть сайт в чистом виде.
Даже надёжная защита иногда не срабатывает, и вирус попадает в код через уязвимый модуль или старый плагин. Необходимо держать хотя бы один архив, снятый заведомо до заражения, — без него код чистым не вернуть. Список заражённых модулей специалист сверяет построчно, прежде чем повторно запускать сайт.
Когда услуга по резервным копиям не нужна
Услуга по регулярному созданию копий не нужна, если сайт с несколькими разделами почти не меняется. В таком случае разовый экспорт данных до заметной правки шаблона решает задачу без постоянного архива. Услуга также не нужна, если панель сервера уже сохраняет копию данных ежедневно и эту копию проверяли на деле. Такие случаи специалист определяет заранее, а не в процессе задачи.
Небольшому сайту с несколькими разделами, как правило, достаточно данных, которые уже лежат у разработчика в переписке. Если правки редки, а нагрузка невелика, платная услуга по регулярному экспорту не нужна вовсе. Короткого архива раз в месяц хватает с запасом. Той же логике подчиняется тестовый сайт для разработки: там копия нужна редко и по запросу.
Что в итоге получает администратор
Большинство пользователей получают готовый архив, ссылку на скачивание и короткую памятку с необходимым минимумом действий. Если нужна помощь специалиста, памятка указывает следующий шаг без долгих объяснений. Простое правило: раз в месяц открывать архив и проверять код на признаки вируса.
Хорошим сигналом считается архив, который открывается без ошибок и совпадает по дате с последней правкой сайта. Если такого архива нет, экспорт данных повторяют заново, а не полагаются на память о последних изменениях. Дата в имени архива облегчает поиск нужной копии среди прочих.
Как устроена работа
Заявка
Задача описывается, доступы к сайту передаются.
Оценка
Срок и количество часов называются до начала работ.
Работа
Выполняется с сохранением резервной копии до изменений.
Отчёт
Показывается, что сделано и сколько времени заняло.
Из практики: Полимерные полы в Москве
- Лента блога снова показывает статьи. Лента /blog/ выводила только пагинацию: шаблон карточки срабатывал лишь в архивах. Шаблон исправлен — в ленте все 14 статей, у записей без обложки нет пустых картинок.
- Битый адрес рубрики в карте сайта. Адрес рубрики блога из карты сайта отдавал 404. Настроены постоянные переадресации на ленту, рубрика убрана из карты сайта как дубль.
- Убраны контакты другой компании. С сайта убраны оставшиеся от шаблона контакты, название и материалы других компаний, в том числе чужие акции и галерея работ.
Реакция на задачу — 1 рабочий день. Работа на любой CMS — 1–2 дня. Всё — по договору, доступы остаются у владельца: что в договоре.
Все примеры работ →«Большая часть того, с чем приходят, — не авария, а накопившиеся мелочи: чужой счётчик, битая ссылка в меню, форма, которая отправляет не туда. Каждая такая мелочь чинится за день.»
Частые вопросы
Сколько это стоит?
Цена работы: 2 200 ₽ / час, минимум 1 час.
Как быстро начинается работа?
Ответ: до 15 минут, в рабочее время.
Что входит в работу?
Копии файлов и базы по расписанию; Хранение вне хостинга, чтобы не потерять вместе с сервером; Глубина хранения: сколько дней хранится — остальное в списке выше.
Останутся ли доступы у меня?
Доступы: остаются у вас, ничего не переносится.
Как устроена работа?
Заявка → Оценка → Работа → Отчёт.
Нужны резервные копии?
Описание задачи — срок и объём работ называются до начала.