Для удобства (и безопасности) следует избавиться от пароля и перевести соединение с сервером через SSH публичные ключи.

Копируем файл в Unix системах и на Mac OS:

Копируем директорию вместе с содержимым:

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

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

Также в целях безопасности стоит отключить авторизацию по паролю. Об этом можно узнать из статьи о базовой настройки сервера на Linux.

Вариант 1

На сервере уже есть файл authorized_keys

Переносим его на сервер с помощью команды:

На сервере нет authorized_keys

Вариант 2

Заходим на свой сервер, дальше переходим в папку:

Если её нет, то создадим:

а) Создаем и открываем файл

Добавляем строку со своим ключом и сохраняем файл.

б) Вставляем в конец файла

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

или в таком формате, где-нибудь в заметках, для каждого из своих сайтов:

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

При переносе менять можно всего лишь ip адрес сервера, а пути оставлять прежними. Если вы везде пользуетесь одними инструментами, например, ISP Manager или Vesta, то пути и не меняются. Это очень удобно.

Перенос сайта

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

На старом сервере

Сначала перенесем файлы сайта.

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

Переходим в директорию, которую будем архивировать:

Запаковываем в .tar.gz (сохраняем только папку сайта, без полного пути):

Переносим архив сайта на другой сервер:

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

Затем вводим пароль доступа от нового сервера:

После чего файл будет скопирован на новый сервер.

У меня при команде scp показывает ошибку:

Но, если перед ней указано что-то вроде:

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

Я не знаю с чем связано уведомление No such file or directory, когда при этом всё копируется. Может баг такой. Если вдруг директории такой и в самом деле нет, то в этом случае никакого копирования не произойдет.

Удаляем архив на старом месте. Он нам больше не нужен.

На новом сервере

Заходим на новый сервер. А затем переходим в директорию в которую хотим распаковать архив:

Распаковываем в эту папку все файлы:

Удаляем наш бэкап файл:

Все команды вместе

На старом сервере:

На новом:

Переносим базу данных MySQL

Теперь пришла очередь перенести базу данных сайта.

На старом сервере

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

Экспортируем и архивируем базу данных. В USER и DBNAME вводим название конкретной базы данных и название пользователя для неё, которую хотим экспортировать. Вместо PASS вводим пароль от этой же базы данных.

Переносим на новый сервер:

Вводим пароль от нового сервера. Всё перенеслось, если в конце будет подобное:

Удаляем файл со старого сервера:

На новом сервере

Импортируем базу данных. Вместо BDNAME — название нашей базы данных. Само слово root — не меняем.

Обратите внимание пароль от root доступа к MySQL. Для панели Vesta его можно найти здесь.

Удаляем файл с нового сервера:

Все команды вместе:

На старом:

На новом:

Обычно программы для входа на сервер с помощью SSH не позволяют хранить пароли.

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

Файл создадим функцией Аутоматора (AppleScript), но запустим не саму программу Automator, а только её скриптовую оболочку. В SpotLight Search вбиваем название программы: Script Editor.

Запустится программа с предложением открыть или создать файл. Нажимаем «New Document», на русском будет, вероятно, «Создать документ»:

Откроется окно нового скрипта, куда нужно будет ввести свой код:

А код вводим такой (заменяя ип адрес и пароль):

Затем сохраняем это в качестве программы (Application).

Теперь запустив этот файл запустится соединение с сервером.

Ошибка имеет вид:

Unable to create directory wp-content/uploads/2907. Is its parent directory writable by the server?

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

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

Смотрим кому принадлежит папка:

Из скриншота выше видно, что папка имеет права доступа пользователя root. Для смены прав доступа воспользуемся инструкцией из статьи копирования файлов и папок в Linux.

Заходим на сервер через ssh.

Вводим команду смены пользователя:

где, пользователь на которого меняем:

папка, на которую меняем пользователя:

В результате папка будет принадлежать нужному пользователю:

После этого всё заработало.

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

Сначала подключиться через SSH, а затем ввести команду:

В содержимом файле можно обнаружить логин и пароль для ROOT входа в MySQL:

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

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

О том, как настроить WebDav имеется статья и повторяться не буду. В следующих шагах подразумевается, что ВебДав установлен и настроен.

В новом скрипте мы соединим функции создания MySQL и перемещения на Яндекс Диск. Копии будут хранится на нашем сервере и дублироваться на Яндекс Диск.

Создание папки для резервного копирования

Подключаемся к сайту по SSH.

Подключаем Яндекс Диск:

Создаём там папки:

Отключаемся:

Создание скрипта для резервного копирования

Создаём файл:

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

Содержимое файла:

Теперь на наш скрипт применяем специальные права, чтобы тот мог использоваться в CRON:

При желании скрипт можно запускать и вручную:

Осталось добавить скрипт в планировщик задания. Читайте отдельно, как добавить задание в CRON.

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

Установка ISPmanager 5 Lite

Запустить Терминал и подключиться к серверу, например:

если не указан порт, то по умолчанию используется 22.

При первом подключении, если вы работаете в операционной системе Mac OS появится уведомление:

Надо подтвердить написав:

Скачиваем установочный файл ISPManager:

Запускаем скрипт установки:

Появляется надпись:

Вводим свой ip адрес для которого куплена лицензия ISP Manager, например:

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

Выбрать стабильную сборку с рекомендуемыми программами.

Настройка ISPmanager 5 Lite

Ядро панели управления ISPmanager 5 находится здесь:

Имя IP адреса должно быть вашего сервера.

Заходим по-другой ссылке, а именно в панель управления ISPmanager Lite:

Заходим во вкладку: «Возможности». Делаем двойной клик по «Веб-сервер» и ставим галочку на Nginx.

Дополнительная настройка Nginx

Обязательно внести дополнительные данные в файл:

А именно строчку:

У меня из-за этого не работал импорт базы данных MySQL в phpMyAdmin и через ISPmanager:

Вносим эти данные в эту часть:

! после этого нужно перезагрузить службу Nginx.

Также нужно поправить объём загружаемых файлов во вкладке:

Вместо 2 мб поставить 30 мб.

Донастройка nginx

Увеличиваем производительность сервера путём ограничения нагрузки с одного IP адреса или сервера.

В файле:

Вместо:

Поставить:

В конфигурации отдельных сайтов (раздел www-домены) вместо:

Поставить для сайтов с большим количеством одновременных запросов к базе данных с одного IP:

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

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

Донастройка Apache

По умолчанию было:

По умолчанию поставить:

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

Установка расширения PHP

После установки и первоначальной настройки ISPmanager 5 Lite в расширения php:

Надо добавить следующее:

А затем включить его.

xcache — это дополнительная программа исполнительного сценария PHP, которая путём кэширования, всё значительно ускоряет. Такие программы также называют акселерацией php скриптов. Кроме xcache существуют также eAccelerator, Phpexpress и другие.

Уменьшить размер файла ротации

Открываем файл:

Вносим изменения:

Сами логи для сайтов находятся в настройках отдельных сайтов во вкладке www.

Добавляем сайты в ISPmanager

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

Создаем пользователей в ISPmanager

Одновременно с созданием пользователей отмечаем создание FTP и доменов.

После создания пользователя зайти в WWW-домены и поменять ip адреса.

Создаём базы данных в ISPmanager

Как зайти в PHPmyAdmin чтобы видеть все базы данных

Надо сменить пароль для root, который указан здесь:

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

Не забыть настроить резервное копирование в соответствующей вкладке.

Исправление ошибок и проблем

В процессе настройки иногда возникают какие-то ошибки. У вас могут возникнуть свои ошибки при настройке ISPManager. Я опишу с которыми сам сталкивался.

Для понимания ошибки MySQL, нужно создать в корне своего сайта, файл с любым именем, со следующим содержимым:

Неожиданно перестал работать mysql

Получилось исправить только, когда вписал в MySQL файл:

следующие данные:

и перезагрузил MySQL через службу.

Удаление логов

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

Через менеджер файлов заходим в папки логов, они находятся здесь:

Удаляем этот файл, после этого пространство на диске должно освободиться.

Перезапуск сервисов ISPManager через SSH

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

Вместо restart, если служба остановлена, можно использовать start.

Расшифровка процессов:

Перезапустить панель ISPManager:

Пути к важным папкам и файлам

Логи ошибок:

Apache:

Nginx:

MySQL:

MySQL в Cent OS физически находится здесь:

Пример CRON задания

Добавление задания в CRON

В операционной системе Cent OS (Linux) файл, отвечающий за выполнение заданий, лежит по такому пути: /etc/crontab.

Для его редактирования, заходим на сервер по протоколу ssh.

Для редактирования общего крона на сервере вводим консольную команду:

Для альтернативного внесения в cron — для каждого отдельного пользователя — смотрите ниже.

Исполняемые файлы имеют расширение sh. В начале файла принято записывать:

Как просмотреть логи в CRON

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

Возьмем скрипт из примера резервного копирования данных на Яндекс Диск.

Скрипт лежит в папке my_scripts и называется backup_webdav_day.sh. Для просмотра логов CRON

По умолчанию он имеет такой вид:

Команда означает, что скрипт будет запускаться в 2 часа каждую ночь.

Предположим, что выполнение команды не работает, нам нужно понять, почему так происходит. Изменяем в файле backup_webdav_day.sh данные скрипта, чтобы тот записывал ход выполнения работы в специальный лог файл, который будет создан в той же директории. И меняем время на ближайшее, допустим сейчас 16.00 и мы хотим узнать, будет ли работать скрипт. Тогда делаем его выполнение через 5 минут.

Ждём пока не наступит 16.05, а затем смотрим что показывает файл backup_webdav_day.log.

CRON отказано в доступе / Permission denied

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

или

Это означает, что в операционной системе Linux, нет прав доступа к файлу. В этом случае файлу backup_webdav_day.sh присваиваем права доступа на исполнение – chmod +x:

После этого данная ошибка должна исчезнуть.

Альтернативное изменение cron в Ubuntu

Иногда изменение файла /etc/crontab напрямую не даёт результата.

Также этот способ добавления заданий в cron считается более надёжным. Задания добавляются конкретному пользователю.

Посмотреть, есть ли у пользователя задания в cron

Для внесения изменения в cron используем команду:

Добавляем в конце файла нужные условия, например:

Сохраняем файл и перезагружаем cron

Или так

Полное руководство установки резервного копирования в LINUX на Яндекс Диск есть на сайте Яндекса.

В этой статье отброшено всё лишнее и добавлены конкретные инструкции для установки и настройки резервного копирования в VESTA в CentOS (LINUX) по шагам.

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

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

Устанавливаем консольный клиент Яндекс Диска

Заходим на сайт через ssh.

Создаём файл:

Вставляем в него содержимое:

Сохраняем данные: CTRL + O (буква), подтверждаем – Y, выходим — CTRL+X.

Для проверки цифровой подписи импортируем ключи:

Теперь всё готово для установки Яндекс Диска на сервер Linux:

После установки настраиваем Яндекс Диск:

Вводим свой логин и пароль от учетной записи Яндекс Диска. И указываем путь до backup папки, который использует VESTA: /backup

После ввода данных утвердительно отвечаем на вопрос:

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

Как отключить клиент Яндекс Диска

Команда для остановки клиента:

Если по какой-то причине потребовалось отключить Яндекс Диск из загрузки системы, то редактируем файл:

И удаляем из него строчку:

Более точная настройка резервного копирования

На предыдущих действиях можно остановиться, но мы пойдём чуть дальше.

Открываем конфигурационный файл, который создал Яндекс Диск для своей работы:

Видим содержимое:

Можем поменять его на следующее (дополним комментариями):

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

Для того чтобы Яндекс резервные копии складывал в отдельно-отведенную папку, в панели управления VESTA надо изменить абсолютный путь backup папки.

Как настроить путь до бэкап папки смотрите в общей статье о создании резервных копий на Vesta – в самом конце статьи после заголовка: «Как изменить путь хранения backup в Vesta».

Вместо этого пути:

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

где site_name — имя вашего сайта.

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

Вместо папки с названием сайта, если например, сайтов несколько, можно назвать папку по названию хостинга.

Примечание

Если всё настроено верно, то на Яндекс Диске почти сразу будут появляться все файлы из директории backup. Если что-то не работает, попробуйте исправить ошибки руководствуясь статьёй резервное копирование VESTA. В конце статьи рассказывается как исправить типовые ошибки.

Ошибка может появляться в консоли после команды размонтировать диск. Например, такое уведомление может появиться, если вручную запустить скрипты из статьи «О резервном копировании данных на Яндекс Диска по протоколу WebDAV».

Ошибка выглядит следующим образом:

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

При этом команда не работает:

При желании можно посмотреть какой процесс занимает диск:

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

Для размонтирования диска сразу по команде можно использовать, так называемую, «ленивую» размонтировку:

После этой команды диск будет размонтирован.

Описание даётся на примере сервера CentOS (Linux).

Предполагается, что резервные копии уже складываются в определённую папку. В примере ниже это папка backup, расположенная в корне сервера.

Создавать резервные копии умеют очень многие системы по управлению сайтами (например: VESTA, ISPManager, а также различные WordPress плагины).

Для создания и перемещения резервных данных одним скриптом, не используя сторонние решения, смотрите другую статью: Создание резервных копий и перемещение на Яндекс Диск.

Предварительно устанавливаем Яндекс Диск на свой Linux сервер.

После установки и настройки Яндекс Диска заходим к себе на сервер через Терминал.

Через командную строку создаём на сервере директорию my_scripts и файл скрипта backup_webdav.sh, который будет перемещать резервные копии на Яндекс Диск:

Вставляем содержимое скрипта:

где ключ -r – означает копирование в том числе и папок.

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

Из папки /backup/ данные будут копироваться в папку Яндекс Диска, который подключен по пути /mnt/yandex.

Запуск скрипта вручную:

или если не работает, так:

Можно скрипт внести в задания CRON и назначить расписание.

Добавляем задания в CRON

Открываем файл CRON

Добавляем данные:

На файл backup_webdav.sh нужно выставить права доступа chmod +x, иначе он не будет запускать через CRON. Для этого через командную строку вводим:

Теперь каждый день в 2 часа ночи, резервные копии, созданные сторонними программами, будут перемещаться на Яндекс Диск.

Делаем для скриптов резервную копию

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

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

Если вам не нужно создание копий, а требуется только перемещение, читайте статью: «Как перемещать резервные копии сайта на Яндекс Диск».

Первым делом, на Linux сервер устанавливаем Яндекс.Диск, который будет работать по протоколу WebDav.

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

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

На Яндекс.Диске создаём папки с названием сайта. Затем внутри этой папки создаём следующие папки: day, week, month.

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

Подключаемся к нашему серверу по протоколу SSH.

Создание папок через командную строку:

Ежедневная резервная копия MySQL и одной папке

Теперь создаём папку на сервере, куда будем складывать все свои скрипты – my_scripts и первый файл скрипта backup_webdav_day.sh:

Скрипт будет сохранять ежедневные копии базы данных MySQL и также папку themes (шаблона сайта для WordPress). Я частенько совершенствую дизайн сайта и добавляю какие-нибудь новые элементы. И мне важно иметь копии этих данных на каждый день.

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

Записываем в файл backup_webdav_day.sh следующее:

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

Ручной запуск скрипта:

Еженедельная полная резервная копия

Создаём копию для всего сайта.

Создаём файл скрипта backup_webdav_week.sh:

Записываем в этот файл:

Ручной запуск скрипта:

Ежемесячная полная резервная копия

Создаём копию для всего сайта, которая будет хранится в папке month.

Создаём файл скрипта backup_webdav_month.sh:

Записываем в этот файл:

Ручной запуск скрипта:

Ошибка line 20: /usr/bin/tar: No such file or directory

Если возникает подобная ошибка, значит tar находится в другой директории. Попробуйте изменить /usr/bin/tar на /bin/tar. И запустить скрипт ещё раз.

Добавляем задания в CRON

Открываем файл CRON

Добавляем данные:

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

Делаем для скриптов резервную копию

Копируем папку со скриптами в корневой каталог сайта.

Создаём скрипт очищающий временную папку с кэшем

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

Как разархивировать архив

Для восстановления резервных файлов на сервере используем рекомендациями из статьи «быстрое восстановление резервных копий на сервере Linux».

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

Устанавливаем и настраиваем WebDAV для Яндекс.Диск

Заходим на сервер через консоль.

Устанавливаем на CentOS WebDAV:

Добавляем данные аутентификации Яндекса в специальный файл:

Если возникает ошибка:

Тогда устанавливаем редактор nano.

После строчки:

Добавляем:

Создаём на сервере папку Яндекса, которую будем подключать:

Монтируем Яндекс Диск:

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

Ввод логина и пароля может не понадобится, если вы заполнили в предыдущем действии файл /etc/davfs2/secrets.

Команда для размонтирования диска:

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

Ошибка can’t write entry into mtab

После монтированная часто возникает такая надпись:

Ошибка не влияет на работу. Несмотря на это предупреждение всё прекрасно работает.

Исправление ошибок во время монтирования:

Ошибка found PID file

Ошибка can’t open fuse device

Ошибка rejected Basic challenge

Ошибка the device is found by lsof(8) or fuser(1))

Сохраняем резервные копии на Яндекс.Диск

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

1. Перемещение и копирование резервных копий, созданных сторонними программами.
2. Перемещение и копирование резервных копий, созданных с помощью наших скриптов.
3. Раздельные резервные копии файло базы данных MySQL
4. Еще один вариант копирования файлов на яндекс-диск

Выбираете тот способ, который покажется вам удобнее или проще.

Как разархивировать архив

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

Разберём ошибку на примере размонтирования Яндекс.Диска из статьи «Монтирование Яндекс Диска по протоколу WebDAV (CentOS)».

Сообщение об ошибке:

Ошибка может возникнуть, если перегрузить сервер без размонтирования Яндекс.Диска (или любого другого примонтированного диска) и затем снова запустить подключение диска по WebDav.

Для исправления надо удалить pid:

Разберём ошибку из статьи «Монтирование Яндекс Диска по протоколу WebDAV (CentOS)».

После команды монтирования диска:

и ввода пароля может возникнуть такая ошибка:

Проверяем есть ли модуль fuse:

Если ничего не выводится, включаем:

Перезагружаем сервер:

Дальше монтируем заново:

Разберём ошибку на примере подключения Яндекс.Диска из статьи «Подключение Яндекс.Диска через WebDAV (CentOS)».

После команды монтирования диска:

Может возникнуть следующая ошибка:

Значит в файле /etc/davfs2/secrets вы указали неверные данные имени пользователи или пароля.

Откройте этот файл:

И проверьте внимательно свои данные.

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

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

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

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

Ниже будет пример с абсолютными путями для восстановления файлов сайта на WordPress, который находится на сервере CentOS (Linux) с системой управления сайтами Vesta.

Предварительно через систему управления сайтами (cPanel, Vesta, ISPManager и др.) добавляем свой сайт и создаём FTP пользователя. Также создаём базу данных.

Теперь подключаемся по FTP к своему серверу. И переносим два заархивированных файла (базу данных MySQL и свои резервные файлы) в папку своего сайта public_html.

Подключаемся к серверу через Терминал по протоколу SSH.

Восстанавливаем базу данных MySQL через командную строку

В коде ниже меняем название site_name.ru на название своего сайта. А если требуется, правим и другие пути. Также меняем название mysql_name.sql.gz на имя своего файла базы данных MySQL.

Разорхивируем архив MySQL в файл с названием mysql.sql:

Удаляем архив MySQL (он нам больше не нужен):

Импортируем разархивированную базу данных MySQL:

Вводим пароль от базы данных. После чего импорт будет осуществлён.

Удаляем файл MySQL с сервера:

Восстанавливаем архив резервных данных через командную строку

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

Разорхивируем архив резервных копий файлов в директорию нашего сайта:

После успешной разархивации удаляем с сервера свой архив:

Например вы запускаете скрипт — script_name.sh, а он выдает ошибки:

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

Очищаем backup

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

Заходим на сервер через SSH.

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

Если в графе использовано указано 100%, значит место закончилось. Одна из причин внезапно закончившегося пространства на жестком диске сервера может заключаться в автоматических backup-ах, которые иногда настроены по-умолчанию в «Весте».

Проверяем размер корневого каталога (список папок с размерами):

Проверяем размер домашней директории:

Будет что-то вроде этого:

Удаляем все файлы из директории Бэкапа:

Проверяем размер файлов в директории. Сначала переходим в директорию:

Затем вводим команду:

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

До этого было значение:

Значит каталог backup очищен.

Очищаем логи

У меня два раза происходила ошибка NO LANGUAGE DEFINED при заходе в Весту. Каждый раз на разных виртуальных хостингах. В другой раз переполнился лог файлов.

Сортируем файлы лога по размеру фалов:

Смотрим какой каталог занимает наиболее количество места и сортируем ещё раз:

И ещё раз:

Находим файл самого прожорливого лога (у меня однажды лог занял 30 гб), пусть это будет:

Дальше удаляем его с диска:

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

Очищаем другие директории

Смотрим на что тратится больше всего. Команда выведет все каталоги и файлы в директории.

или так: