mikopbx / modulebackup Goto Github PK

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

Пример запроса и ответа:

curl "http://127.0.0.1/pbxcore/api/sip/getPeersStatuses"

{"jsonapi":{"version":"1.0"},"errors":["500 (Internal Server Error) "],"meta":{"timestamp":"2021-09-08T16:41:54+03:00","hash":"60e752960a547b815a95b8c6f75ffb3e5d4abb36"}}

Развернуты с нуля 2 АТС:
2021.1.54
2021.2.194
Модуль резервного копирования 1.45.

На АТС 2021.2.194 предварительно удалены все настройки. На АТС 2021.1.54 делаю несколько внутренних звонков, в истории звонков отображаются/прослушиваются записи. Делаю бекап всех данных на 2021.1.54, сохраняю локально img файл. Загружаю img файл на 2021.2.194, восстанавливаю все данные из бекапа. Настройки восстановились, история звонков восстановилась, файлы записей разговоров отсутствуют.

Произвел обновление с MIKOPBX ver: 2023.1.223 до MIKOPBX ver: 2024.1.114
Модуль резервного копирования был 1.77, стал 1.86
При попытке начать резервное копирование выходит ошибка в system/message:

daemon.err php.backend[24108]: Failed to mount backup disk... on Backup

Естественно на предыдущей версии все работало. Удалил модуль БЕЗ сохранения настроек. Установил модуль заново. Все настроил. Но ошибка такая же. Мои настройки:

MIKOPBX ver: 2022.1.99, Модуль резервного копирования (Версия 1.55). В настройках расписания не запоминает порт. Прописываем порт SFTP, например, 44422, жмем сохранить. Открываем настройки, а там снова 22.
Но не проверяли пока как это работает в перспективе. Вдруг порт все таки сохраняется, просто при заходе в настройки поле порт не получает значение из конфига, а проставляется по-умолчанию? Обновились только сегодня. Завтра отпишусь сделается ли автоматический бекап

I can't get it in the logs, but every day ModuloBackup appears deactivated, I activate it and the next day it appears deactivated again. Where can I get the error LOG of why this is occurring?

https://qa.mikopbx.ru/14236/ошибка-в-модуле-резервного-копирования

Error loading users from csv

Подскажите, а когда исправят сортировку в модуле резервного копирования? Из релиза в релиз какая-то дичь. Может сделаете формат YYYY-MM-DD ?

https://t.me/mikopbx_dev/6301

https://qa.mikopbx.com/11068/перенос-настроек-с-vm-версии-на-docker

Есть рабочая Mikopbx (VMWare), последней версии 2021.3.86. Захотелось перенести это все в docker. Но, как я понял, docker пока доступен только версии 2021.3.53. Делаю вроде как стандартно - сначала на исходной через модуль backup все архивирую. Потом на другой через этот же модуль все загружаю. Результат - полностью нерабочий образ docker. То есть там даже перестали запускаться все процессы. Вот вывод ps ax:

1 root      0:00 sh /sbin/docker-entrypoint
8 root      0:00 /sbin/syslogd -S -C512

14 root 0:00 /bin/tail -f /dev/null
15 root 0:00 sh
27 root 0:00 ps ax

Как правильно перенести конфигурацию? И вообще, возможно ли это?

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

После настройки Архивации по расписанию, если установить галку: Начать создание копии сразу после сохранения настроек, то после сохранения она переключается обратно в неактивное состояние.

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

Test AWS S3 and Yandex S3 as backup destination

Сам бекап при этом рабочий

При создании бэкапа в docker размер бэкапа 0, в логе системном ошибка
php.backend[7369]: Return value of Modules\ModuleBackup\Lib\Backup::getDockerHdd() must be of the type array, null returned on Modules\ModuleBackup\Lib\WorkerBackup_EXCEPTION

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

При попытке бекапа выдает ошибку:
Oct 29 13:15:03 daemon.err php.backend[10798]: Failed to mount backup disk... on Backup
Локально бекапы создаются.

https://qa.mikopbx.com/10268/переход-с-askozia-4-на-mikopbx-2021

В наличии имеется Askozia 4.1.5, лицензия на CallFlowEditor 4.0.
Переходим на MikoPBX 2021.2.194 по инструкции https://wiki.mikopbx.com/update45
MikoPBX зарегистрировал, модуль резервного копирования установил.
Настройки загружаются, если их заархивировать в zip, но при восстановлении из архива ничего не происходит, просто крутится колесо.

Настроен бекап (MikoPBX ver: 2021.2.194) на внешний сервер через SFTP. Там складируются папки вида: backup_1631494802, backup_1631581203 и т.д.
В каждой папке несколько файлов, среди которых есть resultfile.img (его размер составляет 318 МБ)

1. Установил отдельно новую MikoPBX ver: 2021.2.194.
2. Жму "Загрузите файл для восстановления".
3. Выбираю файл resultfile.img из папки backup_1631581203 (последний бекап от 14.09.2021).
4. Жму "Открыть".
5. Идет прогресс с надписью "Загрузка файла на АТС"
6. Затем надпись "Обработка файла"
7. Доходит до 100% с надписью "Обработка завершена"
   В итоге в списке файл не появляется и таблица пуста "Нет доступных архивных копий"

В консоли в каталоге бекап только это:

~# ls -l /storage/usbdisk1/mikopbx/backup/
total 4
drwxr-xr-x 3 root root 4096 Sep 14 11:30 333447168-resultfileimg
~# ls -l /storage/usbdisk1/mikopbx/backup/333447168-resultfileimg/
total 4
drwxr-xr-x 2 root root 4096 Sep 14 11:30 mnt_point
~# ls -l /storage/usbdisk1/mikopbx/backup/333447168-resultfileimg/mnt_point/
total 0

Когда у нас накрылся сервер с MikoPBX мы с коллегой больше часа промучились с восстановлением бекапа. В итоге просто по SFTP залили на сам MikoPBX в каталог /storage/usbdisk1/mikopbx/backup/ всю папку backup_1631581203 с внешнего сервера. Только тогда архив появился в списке доступных к восстановлению и вышло раскатать бекап.