Как восстановить удаленные файлы ispmanager
Резервная копия — это копия всех сайтов, баз данных и почтовых ящиков пользователя. Резервные копии позволяют:
- восстановить информацию при проблемах в работе сайта;
- восстановить сайт при переносе с сервера на сервер ;
- сохранить данные при возможных перебоях в работе сервера, программных сбоях, проблемах с оборудованием и т.п.
Копия может храниться на сервере с ISPmanager или во внешнем хранилище. В качестве внешнего хранилища вы можете использовать:
- Dropbox;
- Google Drive;
- Amazon S3;
- S3-совместимое хранилище;
- FTP-сервер;
- SFTP-сервер (с подключением по SSH).
По умолчанию резервное копирование для всех пользователей выполняется автоматически один раз в сутки. Вы можете настроить расписание резервного копирования. Подробнее см. в статье Модуль резервного копирования ISPtar.
Резервное копирование не выполняется для директорий и файлов, которые:
- находятся на примонтированных устройствах;
- являются символьными ссылками.
Для работы с резервными копиями перейдите в Резервные копии.
Настройка резервного копирования
При первом открытии раздела Резервные копии ISPmanager предлагает задать настройки резервного копирования. Нажмите ОК, чтобы указать настройки.
Включите опцию Включить резервное копирование, чтобы резервное копирование выполнялось с указанными настройками.
Для того, чтобы включить/выключить резервное копирование для конкретного пользователя, нужно включить/выключить эту опцию в параметрах пользователя.
Укажите настройки выбранного типа хранилища:
- Путь до папки — директория на сервере, куда будут сохраняться копии.
- Код доступа — код доступа к Dropbox. Вы можете перейти по ссылке и авторизоваться в Dropbox. После этого поле будет заполнено автоматически.
- Путь до бэкапов — директория в Dropbox, куда будут сохраняться копии.
- Код доступа — код доступа к Google Drive. Вы можете перейти по ссылке и авторизоваться в Google Drive. После этого поле будет заполнено автоматически.
- Путь до бэкапов — директория в Google Drive, куда будут сохраняться копии.
- Идентификатор ключа — идентификатор ключа доступа.
- Секретный ключ — секретный ключ доступа.
- Корзина (bucket) — имя контейнера Amazon S3 для хранения резервных копий.
Подробнее о настройках Amazon S3 см. в официальной документации.
- Адрес сервера — доменное имя или IP-адрес сервера.
- Порт FTP — порт подключения. Значение по умолчанию — 21.
- Путь до бэкапов — директория на сервере, куда будут сохраняться копии.
- Пользователь — имя пользователя FTP.
- Пароль — пароль пользователя FTP.
- Адрес сервера — доменное имя или IP-адрес сервера.
- Порт SSH — порт подключения. Значение по умолчанию — 22.
- Путь до бэкапов — директория на сервере, куда будут сохраняться копии.
- Авторизация на сервере — тип авторизации: по паролю или ключу SSH. При авторизации по паролю ISPmanager сгенерирует ключ, который будет использоваться для доступа к удаленному серверу.
- Имя пользователя — имя пользователя SSH.
- Пароль — пароль пользователя SSH.
- Закрытый ключ — содержимое закрытого ключа SSH.
Общий объём в байтах. Вы можете указать в этом поле единицу измерения. Например, 100Mib.
- Для локального хранилища ограничение применяется отдельно к каждому узлу кластера. При превышении заданной величины будут удаляться наиболее старые резервные копии;
- Вы можете оставить это поле пустым, тогда резервные копии будут храниться, пока в хранилище не закончится место;
- Вы можете ограничить общее количество резервных копий через параметр конфигурационного файла BackupCountLimit. Значение параметра по умолчанию — 14 (7 ежедневных и 7 еженедельных копий).
В поле Исключить файлы укажите какие файлы не нужно включать в резервную копию. Каждое исключение нужно указывать с новой строки.
- Пути к файлам задаются относительно домашнего каталога пользователя (по умолчанию это /var/www/username/). Например, data/.filemgr-tmp;
- Вы можете использовать символ *, чтобы заменить любые символы в имени файла.
Настройка параметров резервного копирования
Чтобы изменить заданные настройки, перейдите в Резервные копии → кнопка Настройки резервного копирования.
Создание резервной копии вручную
Чтобы создать резервную копию вручную:
- Войдите под учётной записью пользователя: Пользователи → выберите пользователя → кнопка Войти под пользователем.
- Перейдите в Резервные копии → кнопка Новый.
ISPmanager создаст резервную копию и скачает её на ваш компьютер в формате архива tar.gz.
Таким способом вы можете создавать резервные копии не чаще, чем один раз в час. Если в течение часа после создания первой резервной копии повторно нажать кнопку Новый, ISPmanager скачает тот же архив, что и в первый раз.
Восстановление данных из резервной копии
Восстановление пользователя и всех его данных
Существующие файлы не перезаписываются. Перед восстановлением БД пользователей, удалите с сервера одноимённую БД. Если этого не сделать, то ISPmanager дополнит существующую БД, а не восстановит её полностью из резервной копии.
Восстановление удалённого пользователя
Удалённого пользователя можно восстановить из резервной копии под другим именем. Для этого перейдите в Резервные копии → выберите копию → кнопка Смотреть файлы → выберите пользователя → кнопка Восстановить как → укажите Имя пользователя, которому будут восстановлены данные из резервной копии или Создайте с новым именем → Ok. В этом случае ISPmanager не будет восстанавливать совпадающие сущности. Также пользователю будут не доступны резервные копии, созданные под старым именем.
Если восстановить удалённого пользователя из ранней резервной копии, то данные резервных копий, сделанных поздней, будут ему не доступны.
Например, пользователь был удалён 10 марта, а его резервные копии есть за январь и за февраль. После восстановления пользователя из резервной копии за 15 января, он не увидит резервные копии, сделанные позднее этой даты. То есть резервные копии с 15 января до 10 марта будут ему недоступны.
Восстановление отдельных файлов
Чтобы восстановить отдельные файлы из резервной копии пользователя:
Коммерческая панель управления ISPmanager является, пожалуй, самой популярной системой администрирования в Рунете. Она широко используется не только на виртуальных хостингах, но также на VPS и выделенных серверах, поэтому навыки работы с ее админкой пригодятся любому веб-мастеру.
Данный скрипт имеет встроенную систему резервного копирования, однако умение восстанавливать файлы CMS WordPress (WP) вручную никогда не будет лишним. Например, это может пригодиться при переезде от другого провайдера, который использовал cPanel или DirectAdmin. Давайте же научимся работать с бэкапами.
Восстановление файлов в панели управления ISPmanager
1. Перейдите на страницу авторизации по ссылке, предоставленной хостером. Обычно она имеет вид «имя_сайта:1500/ispmgr» или «имя_сайта/manager/ispmgr», однако у разных провайдеров адрес может отличаться.
2. Выберите в меню панели управления «Менеджер файлов», расположенный в блоке «Система».
3. Перейдите в корневой каталог веб-сайта. Обычно он находится по адресу «имя_сайта/www», «имя_сайта/doc» или «имя_сайта/public_html».
4. Выделите все файлы и папки WordPress в окне ISPmanager. Воспользуйтесь следующим приемом: кликните по первому элементу (обычно это — директория wp-admin), прокрутите список вниз, зажмите клавишу Shift, затем щелкните по последнему элементу (как правило, это — файл xmlrpc.php). Далее нажмите на кнопку «Удалить» на панели инструментов.
5. Подтвердите действие во всплывающем окне, нажав на «Ок».
7. Выберите архив с актуальной резервной копией файлов WordPress в интерфейсе ISPmanager, нажмите на «Ок» и дождитесь завершения загрузки.
8. Выделите архив с резервной копией в интерфейсе панели управления и нажмите на кнопку «Извлечь» на панели инструментов.
9. Убедитесь, что в окне менеджера выбран корневой каталог сайта. Теперь нажмите на «Ок» и дождитесь завершения распаковки.
10. Вновь выделите резервную копию и нажмите на кнопку «Удалить».
11. Подтвердите удаление архива с резервной копией с сервера, нажав на кнопку «Ок» во всплывающем окне.
Поздравляем: работы по восстановлению файлов сайта в ISPmanager успешно завершены.
Ситуация: никому не пожелаешь. Сервер с сайтами клиентов перестает отвечать в середине рабочего дня. Клиенты ведут рекламные кампании, поэтому первым делом останавливается реклама и параллельно разворачивается кампания «Попробуй узнай, что случилось, а лучше исправь». Хостинг не выходит на связь, и ты начинаешь чувствовать, что пауза в работе может затянуться.
Через час безуспешных попыток добиться от хостинга вразумительного ответа, принимается решение - экстренно разворачивать сайты на другом, рабочем сервере.
Мы справились с реанимацией сайтов за 3 часа. Если бы у нас была эта инструкция, «подняли» бы их быстрее. Предполагаем, что наш опыт будет полезен коллегам в экстренных ситуациях.
Итак, на упавшем сервере стоит/стояла панель ISP Manager, инкрементальная резервная копия сохраняется каждый день во внешнее облако. Инкрементальность резервной копии заключается в том, что раз в неделю делается полная резервная копия пользователя на сервере (в том числе и сайтов), а в течение недели изменения дописываются в последующие ежедневные копии.
Казалось, все хорошо – резервная копия есть, выполнена в ISP Manager и сайты будут развернуты на другом сервере, где есть ISP Manager.
Это не работает.
- Пункты: «URL архива», «из панели управления ISPmanager 5 (через rsync)», «из панели управления ISPmanager 5 (через backup)» отбрасываем, т.к. сервер-источник отключен.
- Пункты: «из локального архива ISPmanager 4» и «из панели управления ISPmanager 4» также не подходят, т.к. мы работаем с последней версии ISP 5.
- Остаются только пункты: «загрузить архив» и «из локального архива или каталога». По сути это одно и тоже, только в первом случае мы сразу загружаем архив резервной копии прямо с нашего компьютера, а во втором предварительно загружаем архив в определенную папку на принимающем сервере.
НО чтобы мы не делали у нас не получалось восстановить архив.
В каждой архивной версии содержится три и более файла:
В случае если архив занимает более 100 Мб, то он дробится на части:
- F2020-02-16. user_name.tgz.part1
- F2020-02-16. user_name.tgz.part2
- F2020-02-16. user_name.tgz.partN
Где partN – порядковый номер части архива, а user_name – имя пользователя в ISP.
При попытках загрузить каждый файл по отдельности или загрузить все 3 файла вместе в архиве (в случае если сайт небольшой) – мы получали ошибку вида:
Хотя версия ISP донора и версия ISP акцептора совпадают: ISPmanager Lite 5.232.2.
25 Гб, то загрузка/распаковка зависала на 100% и дальше не двигалась.
После безуспешных попыток использования штатных средств и впустую потраченных полутора часов, мы решили сделать выгрузку архивов вручную.
Это работает. Особенно с большими сайтами.
- Сначала открываем *.info – файл последней свежей версии архива. Его содержание примерно такое: Это означает, что перед нами инкрементальная версия архива сайта (т.е. только лишь зафиксированные изменения, а не полностью весь архив пользователя). На это указывает параметр (для полной версии архива мы бы увидели: type=full), а параметр указывает нам, где можно найти свежую версию архива со всеми файлами от которой можно будет отталкиваться.
- Скачиваем базовую и инкрементальные версии архива до ближайшей к нам дате.
- Т.к. сайт большой, то базовая версия архива содержит 251 часть и мы имеем множество файлов, оканчивающихся на *.tgz.partN (где N – порядковый номер архивной части). Чтобы объединить все архивы в один, можно воспользоваться стандартной консольной утилитой TAR на *Unix-системах – побитное склеивание файлов (MAC/Linux - устройства):
на PC можно использовать Total Commander , выполнив команду «Собрать файл» в пункте меню «Файлы»:
Для этого необходимо выбрать файл, оканчивающийся на part1 , кликнуть по «Собрать файлы…» , и вы получите единый архивный файл.
Важно: резервные копии баз данных не создают инкрементальных частей – каждый раз база данных архивируется полностью, поэтому при ручном восстановлении базы данных достаточно распаковать последний выполненный архив системой ISP Manager.Бонус! Распаковка зашифрованного архива
Если Вам «исключительно» повезло и Ваша резервная копия зашифрована, то предстоит сделать следующее:
- Выполнить расшифровку каждого файла в отдельности в *Unix-системе (адекватного метода расшифровки в Windows-системах мы не нашли):
- Побитно склеить каждый файл:
- И собственно произвести распаковку архива.
В итоге
Бонусный вариант нам не достался – архивы не были зашифрованы, поэтому мы за 30 минут выкачали все необходимые части архива, собрали их в один, распаковали и развернули на новом сервере. Сменили A-записи на NS-серверах Yandex и через 15 минут сайты начали открываться по новому месту прописки. Ура!
UPD. С момента падения сервера прошла неделя, но вразумительного ответа от хостинг-компании нет: сервер так и не работает. Вскоре выяснилось, что сервер отключен за неуплату со стороны более крупной хостинг компании, у которой наш «хостинг» брал их в аренду.
Резервное копирование — процесс создания резервной копии, которая предназначена для восстановления данных в случае технических сбоев, повреждения данных или их утраты.
В статье рассмотрим процесс создания резервных копий данных на примере компании Eternalhost. На этом хостинге настроено инкрементное копирование – это метод сохранения информации, при котором архивируются только измененные с момента последнего полного бэкапа данные.
В рассмотренном случае использовался виртуальный хостинг с панелью ISPmanager 5 Lite.
Начало работы
Создание резервных копий происходит автоматически, резервные копии сохраняются на сервера Eternalhost и доступны для работы с ними. Также пользователь может создать одну полную резервную копию вручную.
Для работы с резервными копиями пользователю нужно перейти в ISPmanager и в разделе «Инструменты» выбрать «Резервные копии».
Восстановление из резервной копии в ISPmanager
Каждая резервная копия состоит из трех разделов: Базы данных, Почта и Файлы. Для восстановления одного из этих разделов нужно сделать следующее:
1. Во вкладке «Резервные копии» выбрать нужную дату копии, кликнув на нее. Нажать «Данные».
2. Кликнуть на нужный раздел (Базы данных, Почта или Файлы) два раза.
3. Выбрать данные, которые нужно восстановить.
4. Нажать «Восстановить».
При восстановлении все существующие в резервной копии файлы будут автоматически заменены. Файлы, которые отсутствуют в копии, будут сохранены без изменений.
Новая резервная копия
Пользователь может сделать резервную копию самостоятельно, для этого ему нужно нажать «Новый». Система в то же время сделает копию и скачает ее на компьютер пользователя.
Созданная версия будет содержать полную копию всех данных. Она будет подсвечиваться значком «Резервная копия создана пользователем».
Импорт резервной копии
Для того, чтобы загрузить резервную копию из внешнего источника, нужно выполнить следующую последовательность действий.
Чтобы скачать созданную ранее в ISPmanager резервную копию, нужно:
Настройка собственного хранилища резервных копий
По умолчанию резервные копии сохраняются на сервера Eternalhost. Однако, каждый клиент может настроить резервное копирование на стороннем сервере или в облаке. Для этого нужно сделать следующее:
- Во вкладке «Резервные копии» перейти в «Настройки».
- В настройках резервного копирования поставить галочку напротив «Настроить собственное хранилище».
- Выбрать тип хранилища из предложенных вариантов. Задавать пароль для резервной копии не обязательно. Он используется для шифрования архива. Если поле не заполнено, данные шифроваться не будут.
- В зависимости от выбора типа хранилища нужно задать данные ресурса, на котором будет храниться резервная копия.
Популярные ресурсы для хранения резервных копий
Dropbox
Для выгрузки резервных копий потребуется зарегистрироваться на Dropbox .
Код доступа
Для получения кода нужно перейти по ссылке, указанной над полем «Путь до бэкапов».
«Путь до бэкапов» (заполнять не обязательно)
В аккаунте пользователя будут созданы папки «Приложения» и «ISPsystem», в которые будет сохраняться бэкап сайта.
Google Drive
Для выгрузки резервных копий вам потребуется создать аккаунт Google .
Код доступа
Для получения кода нужно перейти по ссылке, указанной над полем «Путь до бэкапов».
Потребуется войти в аккаунт Google и разрешить приложению ISPmanager доступ к аккаунту.
«Путь до бэкапов» (заполнять не обязательно)
Резервные копии будут сохраняться в папку, соответствующую имени пользователя на хостинге.
Amazon S3
Обязательные для заполнения поля:
Для получения кода и пароля нужно перейти по ссылке, указанной в соответствующем поле.
Потребуется войти в аккаунт Amazon S3 и разрешить доступ к аккаунту.
Яндекс.Диск
На данный момент Яндекс заблокировал приложение ISPmanager, поэтому резервное копирование на Яндекс.Диск сейчас невозможно.
Потребуется сторонний сервер с настроенным протоколом FTP.
Обязательные для заполнения поля:
- Адрес сервера;
- Порт FTP (по умолчанию 21);
- Путь к резервным копиям;
- Пользователь;
- Пароль.
Выгрузка на удаленный сервер через FTP зависит от настроек сервера и учетной записи пользователя на этом сервере.
SFTP (over SSH)
Потребуется сторонний сервер с настроенным протоколом SFTP.
Обязательные для заполнения поля:
- Адрес сервера;
- Порт SSH (по умолчанию 22);
- Путь к резервным копиям;
- Авторизация на сервере.
При выборе «по паролю», будет предложено ввести:
При выборе «по ключу SSH», будет предложено ввести:
Выгрузка на удаленный сервер через SFTP зависит от настроек сервера и учетной записи пользователя на этом сервере.
Читайте также: