Ранее в систему под управлением CentOS 7 был добавлен жестский диск, ранее использовавшийся в другом компьютере так же под управлением Linux CentOS.
Основной раздел был добавлен в систему просто посмотреть что там было (может что-то пригодиться).
Идея — выделить всё свободное место на этом жестком диске под сайт размещающийся на этом сервере http://dekorimage.ru/

Реализация плана будет такова:
1. Сбор информации — как называется диск, какие на нём разделы, что уже замаплено
2. Размапливаем что есть, удаляем разделы
3. Создаём новые

Для сбора информации можно использовать следующие команды

#ls -l /dev/ | grep sd
смотрим все девайсы, отбираем по вхождению sd

lsblk
так же смотрим девайсы, созданные разделы

df –h
информация по разделам

mount
смотрим что уже замонтировано

В моём случае имеем жестский диск
/dev/sdd
и разделы
/dev/sdd1
/dev/sdd2
/dev/sdd3

Третий раздел у меня был замонтирован в /etc/fstab — эту строчку пока закомментируем
больше никаких точек монтирования я не нашел.

Приступаем к удалению имеющихся разделов и созданию нового

parted -a optimal /dev/sdd (параметр -a optimal я добавил т.к. без него чего то там система ругалась на оптимальность распределения места, с ним не ругается)
Вводим команду mklabel
вводим метку диска — msdos или gpt (gpt поновее — я выбрал её)
далее создаём один раздел выделяя под него всё свободное пространство диска
(parted) mkpart primary 0% 100%
для проверки
(parted) align-check opt 1
(parted) align-check min 1
Если выравнивание в порядке, в ответ каждая команда вернет сообщение: «1 aligned».

Создаю файловую систему ext4
mkfs -t ext4 /dev/sdd1

монтирую новый диск
mount /dev/sdd1 /disk3

в папке /disk3 появился папка /lost+found — значит диск замонтировался

так же можно проверить наличие раздела вышеуказанными утилитами (lsblk, df -h)

размонтирую обратно
umount /disk3

Далее — вношу правки в /etc/fstab для монтируемого диска /dev/sdd1
Перезагружаюсь shutdown –r now

Всё!

Для одного из проектов на виртуальной машине 1С Битрик понадобилось включить расширение pdo_sqlite
Как обычно — залез в /etc/php.d/ нашел нужный мне файл 30-pdo_sqlite.ini и переименовал 30-pdo_sqlite.ini.disabled в 30-pdo_sqlite.ini

Расширение не включилось — посмотрел phpinfo() — сам файл 30-pdo_sqlite.ini подцепляется, но сама информация по pdo_sqlite не подключилась
php —ini так же подтвердило подключение модуля

далее решил глянуть инфу с консоли
php -i | grep mysql

тут то в самом начале и обнаружилась проблема

PHP Warning: PHP Startup: Unable to load dynamic library ‘pdo_sqlite’ (tried: /usr/lib64/php/modules/pdo_sqlite (/usr/lib64/php/modules/pdo_sqlite: cannot open shared object file: No such file or directory), /usr/lib64/php/modules/pdo_sqlite.so (/usr/lib64/php/modules/pdo_sqlite.so: undefined symbol: php_pdo_unregister_driver)) in Unknown on line 0

посмотрел — всё Ок, файл /usr/lib64/php/modules/pdo_sqlite присутствует!

В общем не буду томить, решение оказалось очень простым — включение модуля 30-pdo.ini необходимого уже для дальнейшей работы других pdo_*** модулей

Разбирался с проблемой на одном сайте клиента — при резервном копировании, обнаружили что размер файла базы данных просто ужасно огромен.
Как выяснилось, размер некоторых таблиц (например b_stat_path_cache) переваливал за гигабайт.

Вообще, именно за размер этой таблицы отвечают настройки времени хранения в модуле ВЕБ аналитики, конкретно тут:
Админка — Настройки — Настройки продукта — Настройки модулей — Веб-аналитика — закладки «Настройка данных» и «Время хранения».

Но проблема в данном случае оказалась не в этом.
В Битриксе подчищение всего лишнего (и не только!) занимаются так называемые АГЕНТЫ, список которых и статистику из запуска можно посмотреть тут
Админка — Настройки — Настройки продукта — Агенты

Оказалось, на сайте агенты не запускались уже несколько лет, соответственно статистику просто некому было чистить!

ОБЯЗАТЕЛЬНО проверяйте выполнение агентов на сайте под управлением Битрикс CMS

В данном случае, выполнение агентов было настроено на CRON, а сама задача по крону не была настроена
(тут для проверки нужно смотреть логи выполнения crontab в системе, или для начала просто скрипты поставленные на крон)
посмотреть как настроен запуск агентов в Битриксе можно в файле /bitrix/php_interface/dbconn.php
Если перевести выполнение агентов на хиты — нужно убрать константы define(‘BX_CRONTAB_SUPPORT’, true);

Собственно, я так и сделал, после чего обновил главную страницу сайта, после чего обновил страницу с Агентами в админке, и вуаля — в колонке последнего запуска агентов увидел текущую дату.
После чего заглянул в PHPMyAdmin — таблицы почистились!

Задача решена!