В ISPmanager реализована система резервного копирования, построенная на основе ISPtar.
Основные отличия от предыдущей реализации:
BackupCountLimit 7:7
Минимальное рекомендуемое значение параметра BackupCountLimit 2:2. В этом случае будет делаться 2 полных и 2 ежедневных(дифференциальных) копий.
Использование ISPtar позволяет реализовать ряд существенных улучшений:
Открыть настройки модуля резервного копирования можно непосредственно в самом модуле, нажав на кнопку Настройки. В настройках можно установить тип хранилища, параметры хранилища, общий объем резервных копий в хранилище, файлы (можно использовать регулярные выражения) и базы данных, которые стоит исключить из процесса копирования.
Приоритетами запуска можно управлять с помощью утилит nice и ionice. Приоритеты указываются в конфигурационном файле etc/ispmgr.conf параметром BackupCommandPrefix имеющим значение по умолчанию nice -n 10 ionice -c2 -n7.
Это поле позволяет задать максимальный размер, занимаемый резервными копиями на хранилище. При первом подключении локального хранилища будет автоматически выставлено ограничение в 50% от свободного места на разделе, содержащем директорию хранилища, это значение можно изменить. Также с этой версии добавлена защита от переполнения диска локального хранилища: при закачке каждой части в локальное хранилище система проверяет насколько заполнен диск и, если осталось доступно для пользователя менее 5% диска, система пытается удалить старые архивы для освобождения места. Если место освободить не получилось, резервирование закончится с подобной ошибкой в журнале:
backup DEBUG backup2_storage.cpp:119 Available limit with restriction 95 pct '0' mib
backup DEBUG backup2_storage.cpp:120 File size '54' mib
main DEBUG backup2_cp2_server.cpp:354 m_read = 'RELEASE 56686365'
main ERROR Upload failed
libmgr ERROR Error: Type: 'Cant split slices' Object: ' ' Value: 'Part name prefix missed for part ' '
Сканирование хранилища происходит в момент подключения к новому типу хранилища или переключения директории внутри подключенного хранилища.
Первое резервное копирование после смены директории хранилища сформирует полную копию, вне зависимости от наличия полных копий за предыдущие дни.
Чтобы посмотреть содержимое старого файла, скачайте файл из резервной копии.
Чтобы восстановить данные пользователя из резервной копии, перейдите в Резервные копии → выберите копию → кнопка Смотреть файлы → выберите пользователя → кнопка Восстановить → OK. Когда данные будут восстановлены, в интерфейсе ISPmanager появится сообщение "Восстановление из резервной копии успешно завершено".
Задать список исключаемых файлов можно в настройках модуля резервного копирования. Пути задаются относительно домашнего каталога пользователя, например data/.filemgr-tmp. В фильтрах файлов можно использовать регулярные выражения(*). Указанные файлы не будут участвовать в процессе резервного копирования. В поле ниже можно исключить базы. Их нужно указывать в формате полное имя базы в отдельной строке.
По умолчанию резервное копирование делается ежедневно. Для ISPmanager Lite, Pro, Host можно изменить время запуска резервного копирования для задания ISPmanager backup task в модуле Планировщик. Задание в кроне выглядит следующим образом:
0 3 * /usr/local/mgr5/sbin/cron-ispmgr sbin/backup2 >/dev/null 2>&1
Задать временной диапазон, когда должно выполняться резервное копирование, можно через параметр (BackupTimeInterval). Например: BackupTimeInterval 03:00:00-06:00:00 указывает, что резервное копирование должно проводиться с 3х до 6 часов ночи. Резервное копирование отдельного пользователя прерываться не будет. Если система не успеет скопировать всех пользователей в указанный промежуток времени, резервное копирование оставшихся пользователей будет продолжено на следующий день. При этом новых копий за этот день создаваться не будет.
Например: в понедельник 14.09.2015 мы успели скопировать 10 пользователей из 15. Значит, во вторник будут скопированы оставшиеся 5, а следующая резервная копия для всех пользователей будет сделана уже в только в среду 16.09.2015. Резервные копии всех пользователей будут иметь дату 14.09.2015, несмотря на то, что часть пользователей будет скопирована только 15.09.2015
Это можно сделать вручную, из списка резервных копий удалив ненужные. Также можно освободить место в хранилище, задав Общий объем в настройках модуля резервного копирования. После применения настроек старые версии бэкапов будут удаляться до тех пор, пока общий размер не будет соответствовать установленному значению параметра.
При необходимости скопировать большой объем данных, вы можете изменить приоритет резервного копирования в конфигурационном файле etc/ispmgr.conf, за который отвечает параметр BackupCommandPrefix. По умолчанию значение параметра nice -n 10 ionice -c2 -n7.
nice — утилита командной строки, запускающая программу с измененным приоритетом для планировщика задач. Подробности смотрите здесь.
ionice используется для получения и установки класса и приоритета процесса. Подробности смотрите здесь.
После создания резервной копии, в директории /usr/local/mgr5/var/backup/ispmgr создаются файлы вида 2015-08-12.user.tgz и 2015-08-12.user.info. Эти файлы не содержат саму резервную копию, а предназначены для хранения служебной информации.
Файл с расширением tgz хранит данные о файлах резервной копии.
Файл с расширением info хранит информацию о дате создания, имени последнего файла копии, размере и типе бэкапа.
Наличие этих файлов позволяет отображать резервные копии в списке и ускоряет работу за счет обращения к необходимым данным.
Общее кол-во хранимых резервных копий для каждого из пользователей регулируется параметром BackupCountLimit в etc/ispmgr.conf.
Если параметр BackupCountLimit имеет нечетное значение, например 15, то будет 8 полных и 7 ежедневных дифференциальных резервных копий. При превышении лимита будет удаляться в первую очередь ежедневная дифференциальная резервная копия. То есть, количество полных резервных копий и дифференциальных все равно будет стремиться к равному соотношению, но полных копий будет на одну больше.
По техническим причинам до версии 5.65 были исключены из резервного копирования сортировщики почтовых ящиков.
Под пользователем создать резервную копию можно не чаще, чем один раз в час. Иначе будет скачиваться предыдущая закэшированная резервная копия.
Для пользователя доступно создание одной резервной копии независимо от расписания, установленного через планировщик. Создать такую копию можно кнопкой "Новый" в списке резервных копий под пользователем панели. Такая же копия появляется в списке копий при импорте пользователя из архива *.tar.gz, который создается при скачивании резервной копии из панели. Повторное создание пользовательской резервной копии или импорт пользователя из архива *.tar.gz заменит существующую пользовательскую копию.
При удалении пользователя, который содержится в резервной копии, напротив него в списке сохраненных данных появится пиктограмма в виде восклицательного знака. Пиктограмма содержит дату удаления пользователя. После восстановления пользователя пиктограмма не исчезнет.
При первом запуске резервного копирования создается полная резервная копия. В последующие дни, если день недели не воскресенье, создаются ежедневные дифференциальные резервные копии. В воскресенье в любом случае создается полная резервная копия. В первые 14 дней получится соотношение 3 полных и 11 дифференциальных. По прошествии 14 дней начнут удаляться в первую очередь самые старые дифференциальные резервные копии. После того как у полной резервной копии не останется дифференциальных частей, она будет удалена. Следовательно, соотношение 7 полных и 7 дифференциальных резервных копий будет достигнуто приблизительно через 2 месяца.
Автоматическое удаление наиболее старых незаблокированных резервных копий происходит
Блокируются от автоматического удаления последний по дате полный архив, сегодняшний архив и архив, загруженный пользователем (custom).
Под администратором в списке резервных копий доступна кнопка "Удалить".
Для того, чтобы удалить резервную копию вручную, необходимо перейти в директорию /usr/local/mgr5, задать корректно переменную окружения BACKUP_TOKEN и выполнить команду sbin/backup2_cp --delete указав путь к info файлу резервной копии. Значение токена хранится в etc/ispmgr.conf в параметре BackupToken.
Пример удаления одной резервной копии из локального хранилища для конкретного пользователя (username):
BACKUP_TOKEN="type=local;url=/var/backups/";sbin/backup2_cp --delete var/backup/ispmgr/2015-09-08.username.info
Пример удаления всех резервных копии из удалённого хранилища с типом ftp для конкретного пользователя (username):
BACKUP_TOKEN="password=qwerty12345;type=ftp;url=[ftp://backup5.reserv.net;username=ftpuser23|ftp://backup5.reserv.net;username=ftpuser23] "; ls -1 var/backup/ispmgr/*username.info | xargs -I {} sbin/backup2_cp --delete {}
Пример удаления всех резервных копий в локальном хранилище:
BACKUP_TOKEN="type=local;url=/var/backups/";ls -1 var/backup/ispmgr/*.info | xargs -I {} sbin/backup2_cp --delete {}
Изменить размер тома резервной копии через конфигурационный файл etc/ispmgr.conf.
Пример установки размера резервной копии 30 мегабайт
BackupSliceSize 30M
От администратора это не возможно, нужно зайти под пользователем (можно прямо из интерфейса Резервные копии нажать кнопку "Войти") внутрь резервной копии, выбрать файл(-ы)/базу(-ы) и нажать на "Восстановить"/"Скачать".
Архивируются /usr/local/mgr5/etc, /usr/local/mgr5/var/userconf и /etc в архивы вида F2015-09-16.root.tgz
Эти архивы не доступны из интерфейса панели, т.к. работать с ними нужно крайне редко.
Чтобы восстановить данные, нужно перейти в хранилище (например /var/backup). Выбрать файл архива корневого пользователя (обычно, root) за нужную дату и посмотреть содержимое архива командами:
/usr/local/mgr5/sbin/isptar -l F2015-09-16.root.tgz
tar -tf F2015-09-16.root.tgz
После, выбранный файл извлечь:
Пример извлечения файла ispmgr.root.dashboard.xml:
tar -zxvf F2015-09-16.root.tgz usr/local/mgr5/var/userconf/ispmgr.root.dashboard.xml
Временная директория панели: по умолчанию /usr/local/mgr5/tmp Системная директория панели: по умолчанию /usr/local/mgr5/var/backup/ispmgr Размер одной части архива: по умолчанию 100Мб, меняется через опцию BackupSliceSize
При работе с нелокальным хранилищем:
Операция | Описание | Сколько места потребуется |
---|---|---|
Плановое резервирование | Для работы планового резервирования каждая часть по очереди складывается в системную директорию и загружается на хранилище. | Места в системной директории нужно немного больше размера одной части. |
Вызов резервирования пользователем | При вызове резервирования пользователем по кнопке "Новый" копия делается так же как и при общем резервировании. После этого запускается скачивание частей архива с хранилища во временную директорию и одновременно эти части вливаются в архив внутри системной директории. По завершении пользователю отдается в браузер архив, он же в системной директорий лежит в течение 1 часа (закэшированный архив). | Места в системной директории нужно столько, сколько весят архивы всех пользователей (если все в течение часа захотят сделать новый архив). Места во временной директории нужно в два раза больше чем размер части архива. |
Импорт архива пользователем | При импорте архива пользователем, происходит его загрузка в системную директорию, распаковка (при необходимости конвертация), запаковка и отправка по частям на хранилище. | Места в системной директории нужно столько, сколько весят архивы всех пользователей (если все в течение часа захотят сделать новый архив). |
Скачивание архива | При скачивании архива все части скачиваются с хранилища во временную директорию, там же объединяются в один архив. Этот архив перемещается отдаётся пользователю в браузер и в течение часа ещё хранится в системной директорий (закэшированный архив). | Места в системной директории нужно столько, сколько весят архивы всех пользователей (если все в течение часа захотят сделать новый архив). Места во временной директории нужно в два раза больше чем размер части архива. |
Пользователю нужно иметь места как минимум на 1 часть бэкапа (по умолчанию 100Мб), это нужно потому, что архивация выполняется с правами пользователя и часть архива до заливки на хранилище принадлежит пользователю. Сделано так из соображений безопасности.
Если вам крайне необходимо изменить временную директорию, остановите все процессы панели, скопируйте директорию /usr/local/mgr5/var/backup/ispmgr и примонтируйте нужный раздел средствами операционной системы в /usr/local/mgr5/var/backup/ispmgr. Это обычно делается так:
mount --bind /нужный/раздел /usr/local/mgr5/var/backup/ispmgr
На данный момент резервное копирование после изменения пути до временной директории не всегда работает корректно. Не рекомендуется использовать описанный ниже параметр:
Если утилита killall отсутствует, то выполнить:
/usr/local/mgr5/sbin/mgrctl -m ispmgr exit
Чтобы увидеть все подробности работы новой системы резервного копирования в журналах панели нужно добавить следующие строки в etc/debug.conf:
backup2.* 9
backup2_import.* 9
backup2_download.* 9
backup2_cp.* 9
restore2.* 9
backup2_cgi.* 9
backup2_conv.* 9
backup2_system.* 9
и завершить работу панели командой killall core в SSH-консоли.
После чего можно включить вывод всех журналов резервного копирования так:
tail -f /usr/local/mgr5/var/backup2*log /usr/local/mgr5/var/restore2.log
cd /usr/local/mgr5 && ./sbin/backup2 &
Будьте осторожны с указанием даты далеко в будущем (больше чем BackupCountLimit/2 недель)! Если сделать копию в будущем и ещё одну с датой больше предыдущей, все копии за настоящее время могут быть удалены системой контроля размера резервных копий (даже если в копии за будущее не будет каких-то пользователей).
cd /usr/local/mgr5 && ./sbin/backup2 --date 2016-05-01 &
Будьте осторожны с указанием даты далеко в будущем (больше чем BackupCountLimit/2 недель)! Если сделать копию в будущем и ещё одну с датой больше предыдущей, все копии за настоящее время могут быть удалены системой контроля размера резервных копий (даже если в копии за будущее не будет каких-то пользователей).
cd /usr/local/mgr5 && ./sbin/backup2 --date 2016-05-01 user1 &
Если у вас нет возможности восстановить данные через панель управления, но есть файлы из хранилища такого вида:
F2016-11-02.user.tgz.part1
F2016-11-02.user.tgz.part2
Вы можете склеить их обратно в архив так:
Команда для Unix (Linux/FreeBSD/MacOS):
cat F2016-11-02.user.tgz.part1 F2016-11-02.user.tgz.part2 > F2016-11-02.user.tgz
Команда для Windows:
copy /b F2016-11-02.user.tgz.part1 + /b F2016-11-02.user.tgz.part2 F2016-11-02.user.tgz
Полученный архив F2016-11-02.user.tgz уже можно будет открыть стандартными средствами вашей ОС, но его импорт в ISPmanager невозможен.
Возможна ситуация, при которой уже сделанные резервные копии внезапно удаляются из хранилища. При получении таймаута в 15 минут при FTP хранилище система резервного копирования считает, что кончилось место и удаляет наименее значимый бэкап из старых.
В случае, если каталоги пользователей подключены как отдельные разделы, их файлы из домашней директории(например, /var/www/user/data/www/*) не будут включены в резервную копию.
При необходимости удалить директорию в хранилище GoogleDrive, сначала необходимо отключить резервное копирование в ISPmanager, иначе поведение резервного копирование будет непредсказуемым.