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

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

Итак, все работает гладко, и вдруг что-то происходит. Оно ушло. Ваши файлы отсутствуют.

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

Что может пойти не так?

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

Не так быстро….

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

Именно здесь резервное копирование веб-сайта становится важным!

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

Зачем делать резервную копию вашего сайта?

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

1. Вредоносное ПО/программы-вымогатели

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

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

Думайте об этом как о своем доме; его можно было бы запечатать, как Форт-Нокс, но тогда никто вообще не смог бы войти, поэтому нужны двери. Конечно, у ваших дверей хорошие замки, но кто-то всегда может проникнуть через окно.

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

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

2. Удаленные файлы/неверные команды/человеческие ошибки.

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

(В Linux команда rm -r имя_каталога удаляет каталог и все файлы в нем, часто без подтверждения, что еще хуже, rm -rf / может удалить из корня даже файлы, доступные только для чтения, и все, что по сути убьет ваш Вся машина!).

3. Хаки

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

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

4. Плохой разработчик/сотрудник/кто бы то ни было.

Многие компании в значительной степени полагаются на третьих лиц при разработке наших сайтов. В большинстве случаев веб-разработчики так же честны, как и все мы. Большинство (например, <smile>С уважением</smile>) — замечательные и честные люди (и скромные!).

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

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

5. Сбои сервера

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

Но даже у лучших провайдеров есть проблемы.

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

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

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

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

Кроме того, фермы серверов могут стать объектом скоординированных атак типа «отказ в обслуживании» (DDOS), которые в крайних случаях могут потребовать полной перезагрузки; это всегда сопряжено с потенциальным риском потери некоторых или всех данных.

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

Что следует резервировать на своем веб-сайте?

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

1. Файлы

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

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

2. База данных

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

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

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

3. Учетные записи электронной почты

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

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

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

1. Через ваш веб-хостинг

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

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

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

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

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

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

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

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

Однако недостатки связаны именно с вашим хостинг-провайдером. Хотя они могут превосходно размещать ваш сайт, никогда не разумно хранить все яйца в одной корзине.

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

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

2. Плагины резервного копирования веб-сайтов CMS

Если вы используете популярную CMS, например WordPress, вы можете установить множество плагинов, например Backup Buddy. Они очень удобны и, как правило, очень просты в установке.

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

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

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

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

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

Если вы используете Linux или любую из его производных, вам, вероятно, захочется запустить сценарий оболочки, пакетный файл в Windows или файл MacOS на Mac.

3. Резервное копирование веб-сайтов вручную.

Многие из нас, возможно, знакомы со «старым школьным» способом резервного копирования файлов: создание копий всех файлов и помещение их на съемный жесткий диск или хранение в облаке.

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

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

Однако есть ключевое отличие…

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

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

Резервное копирование базы данных на самом деле относительно просто, особенно если вы используете MySQL. Вам просто нужно получить SQL-дамп базы данных; это просто текстовый файл, содержащий все содержимое вашей базы данных.

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

Метод командной строки

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

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

Метод PhpMyAdmin

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

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

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

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

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

4. Услуги резервного копирования веб-сайтов

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

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

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

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

• Sucuri Backups – отличное решение, поскольку мы рекомендуем использовать Sucuri для безопасности вашего сайта.
• КодГард
• Резервное копированиеGuard
• Удалить мой сайт

Стратегия резервного копирования веб-сайта: лучшие практики

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

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

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

1. Как часто делать резервную копию вашего сайта?

Это важно. Хотите ли вы выполнять резервное копирование ежедневно или ежемесячно?

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

2. Автоматизированное планирование

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

3. Используйте удаленное хранилище

Где вы храните эти данные? Вам не захочется просто хранить копии на своем сервере или даже на своем ноутбуке. Собираетесь ли вы использовать внешний жесткий диск? Облако? Какой облачный сервис?

4. Срок хранения

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

5. Шифрование

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

Разработайте план хранения резервных копий в зашифрованном и защищенном виде (256-битное шифрование с закрытым ключом AES и транспортная безопасность TLS/SSL). Узнайте больше о шифровании.

6. Храните резервные копии на RAID-массивах.

RAID-массивы (избыточные массивы независимых дисков) — это не только хорошая идея для создания нескольких копий вашего веб-сайта и/или данных, но и повышение производительности.

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

7. Выборочное восстановление

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

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

На самом деле распространенной ошибкой является замена всего, если что-то пойдет не так. Конечно, это сработает, но вы потеряете все, что произошло после последнего резервного копирования.

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

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

Итак, ваш сайт исчез, но у вас есть резервная копия. Как восстановить сайт из резервной копии? Это относительно просто.

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

Возьмите файл SQL (текстовый файл, который был создан во время дампа SQL) и либо воссоздайте базу данных с помощью командной строки, либо, если вы используете phpMyAdmin (или любую другую графическую систему управления базами данных, например MySQL Workbench), и либо импортируйте файл, либо скопируйте все это в окно SQL и запустите.

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

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

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

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

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

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

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

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

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

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

Ниже приведены два самых популярных репозитория Git.

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

Заключение

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

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

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