Проблема с дисковым пространством с расширенными отчетами после обновления с 2.2.3 до 2.2.6

У меня большая странная проблема. Я обновил 3 дня назад с Magento 2.2.3 до 2.2.6. Все прошло просто замечательно. Но на следующий день после обновления я получил предупреждение от монитора работоспособности сервера о проблеме с дисковым пространством. Файл был создан в корне сервера, в папке /tmp/analytics:

~ tmp-1537660818.7487 смола. смола: 11 г

через 3 дня после этого у меня в этой папке 3 файла:

~ tmp-1537660818.7487 тар.тар : 11 Г

~ tmp-1537747210,659 смола.смола: 6,5 М

~ tmp-1537833608.7409 смола. смола: 2 г

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

x order_addresses.csv
x ../: Path contains '..'
x .././: Path contains '..'
x ../././: Path contains '..'
x .././././: Path contains '..'
x ../././././: Path contains '..'
x .././././././: Path contains '..'
x ../././././././: Path contains '..'
x .././././././././: Path contains '..'
x ../././././././././: Path contains '..'
x .././././././././././: Path contains '..'
x ../././././././././././: Path contains '..'

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

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

Vendor/magento/module-sales-analytics/etc/analytics.xml

Vendor/magento/module-sales-analytics/etc/reports.xml

Есть идеи о том, что может вызвать эту проблему?

**** РЕДАКТИРОВАТЬ 1 ****

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

**** РЕДАКТИРОВАТЬ 2 ****

Распаковка файлов tar с помощью tar ztvf yourfile.tar.gz дает мне другие результаты:

-rw-rw-r--  0 domainuser psacln 100669 26 sep 02:00 order_addresses.csv
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 ../
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 .././
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 ../././
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 .././././
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 ../././././
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 .././././././
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 ../././././././
drwxrwxr-x  0 domainuser psacln      0 26 sep 02:00 .././././././././

Прошлой ночью сервер снова застрял с файлом 13G.

**** РЕДАКТИРОВАТЬ 3 ****

Я попытался открыть файл с помощью 7zX, он бесконечно повторяется. Я также попробовал использовать приложение под названием Декомпрессор (2.0.2), и оно создает папку с предупреждением об ошибке. Папка содержит файл order_addresses.csv с 5 столбцами: идентификатор сущности, идентификатор клиента, город, регион, идентификатор страны. Но я не могу найти то, что создает или пытается создать, или, по крайней мере, пытается обрабатывать этот файл каждую ночь...

Опять же, единственное место, где я могу найти упомянутые адреса заказов, находится в поставщик/magento/модуль-продажи-аналитика... Есть идеи?

**** РЕДАКТИРОВАТЬ 4 ****

Модуль-продажи-аналитика, похоже, используется Расширенным модулем отчетности, который с моей стороны с самого начала очень глючит! Это всегда приводит меня к 404. Я попытается перенастроить модуль или отключить его.

**** РЕДАКТИРОВАТЬ 5 ****

Настройка/конфигурация:

Linux dedicated server 
CentOS 6.9 
Plesk Onyx Version 17.5.3 
PHP 7.0.32 
Document root : httpdocs/pub 
Include_path : .:/var/www/vhosts/mydomain.com/httpdocs/vendor/magento/zendframework1/library

**** РЕДАКТИРОВАТЬ 6 ****

Повторная авторизация пользователя Magento Analytics ничего не изменила, этой ночью он все еще получил файл 13G. Я просто отключил Расширенный модуль отчетности , чтобы увидеть изменения.

**** РЕДАКТИРОВАТЬ 7 ****

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