Бэкап сайта

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

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

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

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

Что такое бэкап WordPress?

Если вы не имеете богатого опыта работы с WordPress, то вы возможно не знаете, что означает и включает в себя бэкап (резервная копия). Не стоит беспокоится, здесь нет ничего сложного, когда дело касается полного резервного копирования.

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

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

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

Чрезмерный стресс

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

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

Потеря времени

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

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

Потеря дохода

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

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

Особенно это неприятно, когда вы платите за трафик:

Сломанный сайт подрывает доверие к вашему бизнесу

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

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

Резервная копия – необходимость

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

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

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

Что это значит для владельца?

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

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

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

Вариант 1 – Бэкап WordPress сайта с помощью панели управления Hostinger

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

ДОПОЛНИТЕЛЬНО: Постарайтесь взять в привычку делать несколько копий бэкапов во время процесса резервного копирования. Одну сохраните на ваш компьютер, вторую отправьте на вашу почту или загрузите на одну из облачных платформ, вроде Dropbox или Google Drive. Также, не забудьте соответствующе пометить бэкап, чтобы облегчить процесс поиска нужного в будущем.

Создание бэкапа WordPress с помощью cPanel

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

Нажмите на вкладку Бэкапы для просмотра списка доступных бэкапов:

Если вы используете Hostinger, то вы можете скачать нужные вам бэкапы с помощью данной панели.

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

Вот и все! Создание полного бэкапа WordPress завершено.

Вариант 2 – Как сделать бэкап WordPress с помощью FTP и phpMyAdmin

Не стоит волноваться, если вы раньше не использовали FTP или phpMyAdmin. Процесс довольно простой, мы просто скачаем файлы WordPress на ваш ПК. Для скачивания файлов WordPress мы воспользуемся FTP, а для скачивания базы данных phpMyAdmin.

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

Что такое каталог WordPress?

Каталог WordPress – это папка на вашем сервере, где хранятся файлы вашего WordPress. В большинстве случаев это public_html или Home. Если вы установили WordPress в подкаталог, например https://www.пример.ru/вашсайт, вашим каталогом WordPress будет вашсайт.

Каталог WordPress содержит подпапки, вроде wp-includes, wp-content, wp-admin, а также файлы index.php, wp-config.php и т.д. – все они необходимы для работы вашего сайта.

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

Создание бэкапа вашего WordPress с помощью FTP

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

FTP хост – например ftp.hostinger-tutorials.ru
Имя пользователя – имя пользователя, которое вы выбрали при создании аккаунта
Пароль – соответствующий пароль
Порт – обычно он имеет значение 21, если ваш хостинг не указывает другое

Успешное FTP подключение к вашему каталогу WordPress с помощью FileZilla должно выглядеть вот так:

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

Далее, выберите все файлы и папки из вашего каталога WordPress. Затем нажмите на них правой кнопкой мыши и выберите Скачать из появившегося меню:

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

Создание бэкапа базы данных WordPress с помощью phpMyAdmin

Этот процесс тоже довольно прост и займет не более пары минут. Вновь войдите в панель управления cPanel и найдите вкладку phpMyAdmin. Обычно она находится под разделом Базы данных:

В некоторых панелях управления хостингом, нажатие на вкладку phpMyAdmin сразу откроет вам главный экран phpMyAdmin, который выглядит вот так:

Hostinger Бекап WordPress phpmyadmin главная

Здесь вы сможете выбрать нужную вам базу данных.

Однако в Hostinger, при нажатии на вкладку phpMyAdmin вы попадете на страницу со списком ваших баз данных:

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

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

Как найти базу данных вашего WordPress

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

Откройте wp-config.php с помощью удобного для вас текстового редактора (мы рекомендуем Notepad++ или SublimeText):

Найдите такую часть кода:

// ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define('DB_NAME', 'u407433405_ahuda');  /** MySQL database username */ define('DB_USER', '**********');  /** MySQL database password */ define('DB_PASSWORD', '**********');  /** MySQL hostname */ define('DB_HOST', 'mysql');

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

/** The name of the database for WordPress */ define('DB_NAME', 'имя_вашей_базы_данных');

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

Подготовка завершена и можем наконец приступить в главному.

Бэкап вашей базы данных WordPress

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

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

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

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

Вариант 3 – Плагины для бэкапа WordPress

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

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

BackWPup

С более чем 20 бесплатными плагинами в хранилище WordPress, включая такие плагины как Adminimize и Search & Replace, Inpsyde GmbH – это отличный разработчик, который достоин внимания.

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

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

Премиум версия BackWPup имеет еще более расширенный функционал.

VaultPress

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

В вопросе резервного копирования WordPress, VaultPress является несомненным лидером. Плагин “…без устали производит резервное копирование каждой записи, комментария, медиафайла и других частей вашего сайта.” Другими словами, VaultPress создает ежедневные бэкапы WordPress и хранит в защищенном месте.

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

BackupBuddy

Известный как “…оригинальный плагин WordPress для бэкапов…”, BackupBuddy от ithemes – это расширенный плагин для бэкапов WordPress. Благодаря данному плагину, вы можете создать бэкап вашего сайта в один клик в панели управления WordPress.

Помимо функции полного бэкапа, BackupBuddy поставляется вместе с другими полезными функциями, вроде инструмента переноса сайта, автоматического бэкапа, удаленного бэкапа в Dropbox, Amazon S3, Google Drive и других.

Связанные руководства

Если вы хотите узнать больше информации по данной теме, посетите данные руководства:

Как Восстановить Сайт на WordPress с Помощью Бэкапа Базы Данных
Как Сделать Резервное Копирование Писем
WordPress Codex Резервное Копирование

Заключение

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

В данном руководстве мы показали несколько способов, как сделать бэкап WordPress сайта. Знаете еще? Поделитесь своими способами в комментариях.

www.hostinger.ru

Понятие резервного копирования.

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

Кто делает резервные копии?

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

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

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

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

Как часто делать копии?

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

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

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

Сколько копий делать?

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

Какие способы резервного копирования использовать?

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

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

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

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

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

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

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

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

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

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

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

Для выгрузки резервных копий нажмите на кнопки «Выгрузить» напротив нужной копии.

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

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

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

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

Далее, перед вами откроется раздел «Резервные копии», где вы также можете воспользоваться автоматическими копиями или создать бэкап самостоятельно.

Для этого нужно выбрать сайт и нажать напротив него на иконку зелёной стрелочки.

Так, вы сделаете резервную копию файлов сайта.

Затем переходите в подраздел «Базы данных», выбираете базу и также жмёте на зелёную стрелочку.

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

Как видите, принцип одинаков, кнопочки разные. ?

Как создать резервную копию сайта с помощью FTP и phpMyAdmin.

Этот способ посложнее и требует определённых знаний, и приходит на выручку, когда у вас есть только доступ к ftp и phpMyAdmin.

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

Алгоритм действий простой:

— создаёте на компьютере папку,

— подключаетесь к сайту по ftp,

— копируете содержимое сайта в папку на компьютере.

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

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

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

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

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

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

Вот такая вот хитрая процедура.

Это были проверенные способы, которые выполняются вами с полным контролем над процессом.

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

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

Друзья, у меня на этом всё. Желаю вам успехов и хорошего настроения!

С уважением, Максим Зайцев.

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.

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

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

joomla.ru

Что такое скрипт?

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

Зачем нужен скрипт для бэкапа?

Польза от такого формата очевидна — однажды написав скрипт, его можно выполнять многократно, причём автоматически и по расписанию. Именно это и требуется для решения задачи по созданию резервных копий. Бэкапирование сайтов и VPS поддерживается у многих хостеров, у некоторых по умолчанию, у некоторых это дополнительная услуга. Ведь для хранения бэкапов требуется дисковое пространство. Если проекты небольшие и бэкапы занимают несколько мегабайт, то это не создаёт проблем. Но если резервные копии ваших сайтов занимают несколько гигабайт, то бэкапить это становится сильно сложнее.

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

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

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

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

А для тех, кто хочет разобраться во всём до конца и настроить самостоятельно — едем дальше.

Требования к бэкапам сайта

Итак, подведём промежуточный итог в виде требований к нашим резервным копиям:

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

Дело за малым — создать такое решение. 2 и 3 пункты могут ввергнуть вас в когнитивный диссонанс, но сейчас дойдём до этого и станет понятней.

По первому пункту должно быть всё понятно, но всё же немного раскроем тему.

Какие части сайта нужно бэкапить?

Сайт обычно состоит из CMS и файлов. Мы не будем их разделять и пусть это будет одна составляющая — файлы.

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

Но чаще всего сама CMS имеет небольшой объём относительно всего проекта, или в принципе. Поэтому проще сохранять в резерве всё подряд.

Как и чем делать бэкапы файлов сайта

В unix-системах, есть пару штатных средств которые лучше всего для этого подходят. Это архиватор — утилита tar, которая используется в связке с компрессором gzip.
tar zcfv backup-`date +%y%m%d`.tar.gz /var/www/myhosting/

На выходе получается архивный файл, в который упакованы сжатые файлы проекта.

Чем делать бэкапы большого размера?

При малом объёме данных такой подход себя оправдывает. Но если проект занимает сотни мегабайт или даже гигабайты — такой вариант очень плохо подходит для резервного копирования, поскольку сжатие будет занимать кучу времени и прилчно отъедать ресурсы системы. К счастью, в Linux имеется прекрасная штука rsync. Это утилита для синхронизации файлов. Это даже не просто утилита, а целый протокол, активно используемый для некоторых задач, но для нас интересна именно утилита. И что ещё важнее, она умеет работать поверх SSH, что нам пригодится в дальнейшем.

Простейший пример использования:
rsync -avh /var/www/site.com/ /var/backup/site.com

Эта команда полностью зеркалирует папку /var/www/site.com/ с папкой /var/backup/site.com. Я говорю — зеркалирует, потому что это не просто копирование, а именно синхронизация. Для неё характерны следующие особенности:

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

Как сделать бэкап базы данных сайта?

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

Тут есть хорошая новость. Большинство хостеров регулярно делает резервные копии всех баз данных, которые у них хостятся на виртуальном (shared) хостинге.

Однако, в случае с ВПС/ВДС тут уже нельзя сказать так однозначно. Если вы держите свои сайты на отдельном виртуальном или выделенном сервере, то это предполагает, что вы сами в состоянии озаботиться такими вещами. Хостер же, банально может не иметь доступа к вашим БД и даже не знать об их существовании. Чаще всего так и происходит.

Для бэкапов БД существует также множество способов, но все они используют вот это:

mysqldump -u dbuser -p dbpass dbname > mysql-`date +%y%m%d_%H%M`.sql

Это и phpmyadmin, и панели управления вроде ISP и сторонние утилиты вроде Navicat. Все они используют штатные утилиты самой СУБД и работают поверх них. Однако, штатные утилиты имеют преимущество — бэкапы сохранённые с их помощью всегда гарантированно рабочие. Что же касается сторонних решений — тут надо только надеяться на то, что оно делает действительно целостный бэкап. В случае с mysql, на котором работают большинство сайтов — это утилита mysqldump. Если используется БД postgesql — команда будет выглядеть несколько иначе, но это тоже будет штатная утилита самой Postgres:

pg_dump -U user -Fc dbname > pgsql-`date +%y%m%d_%H%M`.dump

В данном случае используется специальный формат дампа — Custom, доступный в Postgresql. Он гораздо удобней обычного SQL, но таковой в постгрес тоже доступен — просто нужно выполнять эту команду без опций Fc.

Куда сохранять бэкапы сайта?

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

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

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

Как настроить автоматический бэкап сайта по расписанию?

Но меня не прошибает пот. Потому что файлы всех сайтов на впс сбрасываются в соседнюю папку, каждые два часа. А если вирусы или взломали сайт? это ведь можно заметить гораздо позднее, чем через 2 часа, тогда в бэкапе тоже будут испорченные данные. Верно. Поэтому есть ещё одна папка, куда сбрасываются все файлы раз в 3 дня. У меня записано в crontab:
0 */2 * * * rsync -avh /var/www/ /var/h2backup/ #бэкап делается каждые 2 часа 0 1 */3 * * rsync -avh /var/www/ /var/d3backup/ #раз в три дня в час ночи

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

Но ведь это увеличивает объем файлов в 3 раза. Да, увеличивает. Но бэкапов много не бывает, друзья 🙂 Других способов на 100% обезопасить себя от вышеперечисленных неприятностей я не знаю. Если самому можно быть просто аккуратней и внимательней при правке кода, сохранять копию файла перед редактированием , то при работе команды это становится невозможным. И чем больше команда, тем больше верятности, что где-то кто-то накосячит. Что уж говорить о кулхацкерах и вирусах.

Надеюсь по этому пункту всё понятно.

Зачем сохранять бэкапы на удалённое хранилище?

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

Это значит, нужно сохранять свои данные на каком-то облачном хранилище, или, на худой конец, на своём рабочем или домашнем компьютере — это доступно всем без исключения. Особенно, учитывая, что где, как не на личном компьютере, у нас есть сотни гигов, а то и терабайты диска, бесполезно простаивающие или забитые каким-нибудь хламом 🙂 Кстати, именно такая ситуация стала предпосылкой к написанию всего этого талмуда. Один мой знакомый озадачился бэкапированием сайта, в 50 гб объёмом, на свой домашний компьютер. И обратился за помощью ко мне. Подумали, потестировали, и родилось решение — как делать бэкап по SSH на компьютер с Windows.

Если у нас имеется другой ВПС — то можно бэкапить данные на него без особых трудностей. rsync придётся здесь как нельзя кстати. Сделайте авторизацию по ключу, добавьте пару строк в вашем crontab c нужной периодичностью — и можно забыть про бэкапы. Точно также можно сделать и для хранения бэкапов на домашнем компьютере, если там стоит Linux или FreeBSD.

Как бэкапить сайт по SSH на домашний компьютер Windows?

Но вот в случае с Windows придётся заморочиться. Для этого потребуется утилита plink.exe. Получить её можно на putty.org по ссылке here. Она позволяет использовать ssh из командной строки винды. Это маленькая но крайне полезная штуковина поможет создать те самые скрипты для автоматического бэкапа.

Просто создайте текстовый файл с такими строками:
d:plink.exe -pw rootpassword root@example.com -C "mysqldump -uroot -ppassword sitedb|gzip">d:backupsitedb-%date%.gz d:plink.exe -pw rootpassword root@example.com -C "tar czfv - /var/www/example.com/">d:backupexample_com-%date%.tar.gz

здесь rootpassword — это пароль ssh, а -uroot пользователь БД — -uuser, например. -ppassword — пароль этого пользователя, соответственно — —pyourpass, sitedb — имя БД сайта. Здесь не пугайтесь, mysql поддерживает опции слитно со значениями, но можно и поставить пробел — -u user и -p password.

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

Этот же скрипт можно создать через наш генератор скритов для бэкапов.

answit.com

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

Создайте новую задачу с помощью кнопки на панели "Новая задача…", или просто нажав Ctrl+N.

Выберите задачу копирования, перейдите к Шагу 2 и найдите плагин "FTP" на левой панели.
Дважды щёлкните на плагине или нажмите кнопку ">>", чтобы открыть диалог настройки FTP.

Выберите строчку "Новая конфигурация" с помощью двойного щелчка на ней; это откроет диалог соединения.

Введите все необходимые параметры для доступа к веб-сайту по FTP. Закончив, нажмите OK.

Теперь отметьте или сбросьте "галочки" напротив нужных данных в статическом содержимом каталога сайта. Закончив, вновь нажмите OK.

Примечание: для других типов FTP-соединений в программе имеются плагины "SFTP" и "FTPS". Принципы работы с ними точно те же. Плагин FTP понадобится вам в данном примере на Шаге 3.

Далее займитесь динамическим контентом. Вернитесь к Шагу 2 и выберите плагин "MySQL" в группе "Databases", точно так же, как вы перед этим выбирали плагин для доступа к FTP.

Дважды щёлкните на строчке "Новая конфигурация" и откройте диалог конфигурирования доступа к MySQL.

Введите параметры соединения для доступа к контенту веб-сайта через СУБД MySQL.
Щёлкните OK и вернитесь в окно плагина MySQL. Отметьте «галочками» базы данных, которые вы хотите сохранить.

Нажмите ОК для продолжения. Вы вернётесь к Шагу 2. Переходите к следующему шагу.
На Шаге 3 выберите из списка хранилищ плагин FTP. Настройте доступ к нему точно так же, как вы настраивали плагин SFTP на Шаге 2.
Продолжайте создавать задачу в соответствии с Руководством Пользователя. Эти шаги при создании задачи резервного копирования сайта никак не отличаются от описанных в инструкции для общего случая.

www.handybackup.ru

Что такое резервная копия (бэкап) сайта интернет магазина?

Чтобы ответить на этот вопрос, давайте сначала рассмотрим из чего обычно состоит современный сайт.

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

Файлы CMS.
А это уже просто файлы с программным кодом CMS, фотографиями ваших товаров и многим другим.

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

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

И точно так же база данных абсолютно бесполезна при отсутствии файлов CMS.

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

И в случае если вы “случайно” удалите сайт, вам нужно будет просто заново залить файлы CMS на FTP и переустановить базу данных. Если следовать инструкции, это занимает обычно не более 10 минут.

Несколько страшилок

Только реальные случаи из моей практики.

История первая. “Мститель”

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

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

Так как резервные копии не делались, долго и упорно восстанавливалась база данных. На это было потрачено дополнительных 3 недели. Бэкапы на стороне хостинга были совсем устаревшими и не смогли помочь.

История вторая. “Невидимка”

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

Заметили это быстро, так как владелец заходил на свой сайт через iPad

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

История третья. “Недопереехали”

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

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

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

Вывод из всех этих историй: резервная копия всегда страхует от внештатных ситуаций и человеческого фактора.

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

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

Основной минус этого способа: ручной режим и отсутствие автоматизации, но об автоматизации мы поговорим позже

Делаем бэкап базы данных сайта

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

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

Шаг 1. Заходим в веб панель хостинга.

(клик на любом изображении для увеличения)

Шаг 2. После захода в настройки вашего хостинга Hetzner, выберите ваш домен и перейдите в раздел с базами данных.

Шаг 3. Выбирайте базу данных для создания резервной копии. И затем кликайте на phpMyAdmin.

Шаг 4. Кликните на “Экспорт”.
Начиная с этого шага не имеет значения какой у вас хостинг – phpMyAdmin у всех примерно одинаковый.

Шаг 5. Оставьте настройки по умолчанию и кликните на “ОК”.

Шаг 6. Начнется скачивание вашей базы данных и в результате скачается файл название_вашей_базы_данных.sql

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

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

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

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

Шаг 1. Установите FTP клиент на свой компьютер.

Если он у вас уже установлен, то можете смело пропускать этот шаг.

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

Шаг 2. Уточните данные для доступа к FTP серверу, где хранится ваш сайт.

Обычно данные для подключения к серверу хостинга хранятся во соответствующем разделе панели хостинга: “FTP”. Если вы испытываете сложности с их поиском, обратитесь к техподдержке вашего хостинга.

Данные для доступа к серверу выглядят обычно следующим образом:
Сервер: ftp.ваш_хостинг.ru
Логин: <ваш_логин>
Пароль: <ваш_пароль>

Шаг 3. Настройте соединение с вашим хостингом.

Вот скриншот настройки FTP доступа в FileZilla для наглядности:

Шаг 4. Подключаемся к хостингу и ищем папку public_html, именно в ней содержатся файлы вашего сайта.

Если такой папки у вас на хостинге нет, то возможны несколько ситуаций:

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

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

Шаг 5. Копируем файлы.

Просто кликните правой кнопкой на нужную папку и нажмите “Скачать”.

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

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

Следующим шагом мы правильно организуем их хранение.

Как правильно хранить резервные копии?

Главное правило: не хранить все в одном месте!!!

А теперь подробнее…

Вариант №1. Непосредственно на хостинге.

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

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

Вариант №2. Свой собственный компьютер.

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

Вариант №3. Облачное хранение.

Большинство из вас, наверняка, слышало о таких сервисах как Dropbox (рекомендую именного его), Google Drive и Яндекс.Диск. Эти сервисы позволяют хранить файлы на облачных серверах, к которым вы можете получить доступ из любого места где есть интернет. И каждый из этих сервисов предоставит вам бесплатное место для хранения нескольких резервных копий.

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

Важные вопросы и ответы

А мне подойдет изложенный в статье метод?
Я показал метод подготовки резервной копии сайта, который подойдет практически всем владельцам небольших и средних интернет магазинов. Достаточно иметь доступ к FTP и к phpMyAdmin (база данных).

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

У меня популярная CMS. Может есть готовые модули?
Не исключаю. Для всех наиболее популярных CMS есть модули, позволяющие сделать бэкап. Это, например, очень удобно сделано в Битриксе: одним кликом бэкап создается и загружается в облачное хранилище на серверах Битрикса.

Важно!

НЕ ПОЛЕНИТЕСЬ СДЕЛАТЬ РЕЗЕРВНУЮ КОПИЮ ПРЯМО СЕЙЧАС!!!

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

Кстати, если у вас есть интересные истории по теме, буду рад услышать

idivpered.ru