На VPS закончилось место, но сайт занимает мало: поиск логов, кэша и старых бэкапов

Что именно закончилось на VPS: место на диске, inode или отдельный раздел?

Первым делом нужно определить не размер сайта, а состояние файловых систем VPS. Сообщение No space left on device не всегда означает, что закончились гигабайты. Может быть заполнен отдельный раздел или исчерпаны inode из-за огромного количества мелких файлов.

Начните с двух команд:

df -h
df -i

df -h показывает использование дискового пространства. Больше всего интересуют колонки Size, Used, Avail, Use% и Mounted on. Если корневая файловая система / заполнена почти полностью, свободное место на отдельно смонтированном /home ситуацию не исправит.

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

df -Th
lsblk
findmnt

df -i показывает использование inode. Если IUse% дошёл до 100%, Linux больше не может создавать новые файловые объекты, даже если в df -h остаются свободные гигабайты. Такое бывает при накоплении PHP sessions, кэша, почтовых файлов, временных данных и каталогов с сотнями тысяч или миллионами объектов.

После этих двух проверок задача уже конкретная: либо ищем гигабайты, либо ищем огромное количество файлов. Смешивать эти сценарии не стоит — способы диагностики у них разные.

Как за несколько минут найти каталог, который занял диск VPS?

Если df -h показывает, что корневой раздел почти заполнен, а WordPress занимает только несколько гигабайт, искать нужно от корня файловой системы, а не только внутри сайта.

Удобнее двигаться сверху вниз:

du -xhd1 /
du -xhd1 /var
du -xhd1 /home

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

Допустим, основная масса данных оказалась в /var:

du -xhd1 /var

Если там лидирует /var/lib:

du -xhd1 /var/lib

Если /var/lib весит 30 ГБ, а весь WordPress — 3 ГБ, дальше искать плагины бессмысленно. Сначала разбираемся с содержимым /var/lib.

Для конкретного каталога:

du -sh /path/to/directory

Отдельные крупные файлы можно искать через find. Например:

find /var -xdev -type f -size +1G -ls

Порог нужно подбирать под Linux VDS. Файл на 800 МБ может быть существенным на диске 20 ГБ и совершенно обычным на сервере с сотнями гигабайт данных.

Команды du и find могут выполняться долго на каталогах с огромным количеством объектов. Если обход небольшого по гигабайтам каталога неожиданно затягивается, стоит параллельно проверить inode: проблема может быть не в нескольких больших файлах, а в миллионах маленьких.

Если сумма каталогов примерно объясняет Used из df, причина почти локализована. Если же df показывает условные 70 ГБ, а du видит лишь 30–40 ГБ, не начинайте удалять ещё больше. Такое расхождение требует отдельной проверки.

Как понять, что VPS заполнили системные, Nginx, Apache или PHP-логи?

Если /var/log оказался одним из крупнейших каталогов, сначала найдите конкретный журнал. Удалять весь /var/log нельзя: в нём находятся данные разных системных сервисов, и часть из них нужна для диагностики самого сервера.

Как найти самые большие файлы в /var/log?

du -sh /var/log/*
find /var/log -type f -size +500M -ls

Пути отличаются между дистрибутивами и панелями. На одном VPS вы увидите syslog, на другом messages; PHP-FPM unit может называться php-fpm, php8.2-fpm, php8.3-fpm и иначе.

Если найден огромный error.log, не обнуляйте его сразу. Сначала посмотрите последние строки:

tail -n 100 /path/to/error.log

Обычно картина видна быстро: одна PHP-ошибка повторяется снова и снова, приложение не может подключиться к базе, скрипт обращается к отсутствующему файлу или поток запросов создаёт одинаковые сообщения. В таком случае сам лог — следствие. Удалить его можно, но без устранения источника он снова вырастет.

Как проверить systemd-journald?

Часть журналов хранится не в привычных текстовых файлах. Общий размер журналов systemd показывает:

journalctl --disk-usage

Если journald занимает много места, посмотрите не только на размер, но и на поток сообщений конкретных сервисов. Очистить несколько гигабайт несложно. Гораздо полезнее выяснить, какой unit продолжает их генерировать.

Почему удаление активного error.log может не вернуть место?

Nginx, Apache, PHP-FPM или другое приложение может продолжать держать файловый дескриптор уже удалённого журнала. Имя исчезнет из каталога, но блоки на диске останутся занятыми, пока процесс не закроет файл. Поэтому ситуация «лог удалил, а df не изменился» вполне реальна.

Состояние сервисов можно проверить через:

systemctl status nginx
systemctl status php-fpm

Названия unit зависят от системы. Для MariaDB это может быть mariadb, для PHP — unit с номером версии. Команды из статьи нужно подставлять под реальную конфигурацию VPS, а не копировать механически.

Лог не просто большой — нужно понять, кто его пишет. Если причина найдена и поток ошибок прекращён, тогда уже имеет смысл разбираться с очисткой и ротацией.

Может ли кэш WordPress, PHP или веб-сервера занять десятки гигабайт?

Да. Если сам wp-content небольшой, следующий кандидат — кэш вне привычного каталога WordPress. FastCGI cache Nginx, PHP sessions, временные файлы приложения и некоторые виды persistent cache могут занимать диск независимо от размера сайта.

Проверить стоит:

• wp-content/cache и каталоги кэширующих плагинов WordPress;
• FastCGI cache и proxy cache Nginx;
• PHP session storage;
• /var/cache;
• временные каталоги приложений;
• кэш пакетного менеджера;
• файлы persistence Redis, если Redis настроен с RDB или AOF.

Размер известного каталога проверяется обычным du:

du -sh /path/to/cache
du -xhd1 /var/cache

Как найти реальный путь FastCGI cache Nginx?

Не стоит автоматически считать, что Nginx хранит кэш в /var/cache/nginx. Путь задаётся в конфигурации и может быть другим. Посмотреть загруженную конфигурацию можно так:

nginx -T 2>/dev/null | grep -E 'fastcgi_cache_path|proxy_cache_path'

Если команда ничего не выводит, это ещё не ошибка: соответствующий файловый кэш может вообще не использоваться. Если путь найден, проверьте его размер:

du -sh /path/from/nginx/config

Сам факт существования большого каталога не доказывает неисправность. Смотрите TTL, правила очистки и скорость роста. Кэш в несколько гигабайт на нагруженном проекте может быть нормальным; кэш, который бесконтрольно растёт до заполнения VPS, — уже нет.

Где PHP хранит session-файлы?

Для CLI PHP значение можно посмотреть так:

php -i | grep session.save_path

Но здесь есть ограничение: PHP CLI и PHP-FPM могут использовать разные php.ini и разные настройки pool. Если сайт работает через PHP-FPM, проверяйте именно конфигурацию FPM, а не делайте вывод только по CLI.

После определения пути:

du -sh /path/to/php/sessions

Если там сотни тысяч файлов, проблема может одновременно проявляться и по объёму, и по inode.

Как отличить кэш от рабочих данных?

Название каталога cache ничего не гарантирует. Посмотрите владельца, структуру и даты файлов:

ls -lah /path/to/cache

Для WordPress лучше использовать штатную очистку плагина. Для Nginx — сначала выяснить, какой cache_path используется. Для PHP sessions — проверить правила удаления устаревших сессий. В Redis рабочий набор обычно находится в памяти, но при включённом persistence файлы dump.rdb или AOF тоже занимают диск, поэтому большой каталог Redis нельзя автоматически считать обычным кэшем.

После очистки измерьте размер повторно:

du -sh /path/to/cache

Затем повторите проверку через некоторое время. Если каталог снова быстро набирает гигабайты, очистка была только временной мерой. Ищите TTL, лимиты, количество уникальных cache keys или механизм, который должен удалять устаревшие файлы.

Сначала выясняем, чей это кэш. Потом чистим.

Где искать старые резервные копии, если сам сайт занимает мало?

Локальные резервные копии легко объясняют разницу между размером WordPress и заполнением VPS. Сайт весит 4 ГБ, но рядом лежат пять архивов по 4–5 ГБ. Рабочий сайт по-прежнему небольшой, а диск уже почти занят.

Бэкапы могут находиться в:

• /backup и /backups;
• домашнем каталоге пользователя;
• /root;
• каталогах панели управления;
• wp-content или директории WordPress-плагина;
• временных каталогах после переноса сайта на VPS.

Для поиска крупных архивов в текущей файловой системе:

find / -xdev -type f \( \
-name "*.tar" -o \
-name "*.tar.gz" -o \
-name "*.tgz" -o \
-name "*.zip" -o \
-name "*.sql" -o \
-name "*.sql.gz" \
\) -size +500M -ls

-xdev здесь принципиален: команда не переходит на другую файловую систему. Это уменьшает шум и случайный обход подключённых хранилищ, но означает, что отдельный /home, /backup или другой mount нужно проверять отдельно.

df -Th
find /home -xdev -type f -size +500M -ls
find /backup -xdev -type f -size +500M -ls

Пути, которых нет на конкретном VPS, просто пропускаются.

Как найти старые архивы, а не только большие?

Возраст можно использовать как дополнительный фильтр. Например, чтобы увидеть файлы старше 30 дней:

find /path -xdev -type f -mtime +30 \( \
-name "*.tar.gz" -o \
-name "*.zip" -o \
-name "*.sql" -o \
-name "*.sql.gz" \
\) -ls

Это команда поиска, а не удаления. Возраст файла сам по себе не означает, что backup больше не нужен.

Почему бэкап внутри сайта может расти особенно быстро?

Если резервная копия сохраняется внутри дерева, которое потом снова архивируется целиком, предыдущий архив может попасть в следующую копию. Эффект зависит от исключений конкретной системы резервного копирования, поэтому сначала сравните содержимое и размеры последовательных архивов.

Есть ещё один сценарий: панель сначала создаёт архив локально, затем отправляет его в удалённое хранилище. Передача завершается успешно, а временная локальная копия по какой-то причине остаётся. Через несколько циклов внешний backup работает исправно, но локальный диск всё равно заполняется.

После удаления подтверждённо ненужной копии повторите:

df -h

Если место вернулось, проверьте не только текущий результат, но и retention. Иначе через несколько циклов резервного копирования диск снова окажется в том же состоянии.

Почему MySQL или MariaDB могут занимать намного больше места, чем файлы WordPress?

Каталог WordPress не включает физические файлы базы данных. Поэтому wp-content может занимать 3 ГБ, а /var/lib/mysql — ещё десятки гигабайт. Особенно заметно это на WooCommerce, сайтах со статистикой, журналами активности, очередями, сессиями и давно работающими плагинами.

du -sh /var/lib/mysql

Если каталог базы неожиданно самый большой, здесь стоп: не удаляйте из /var/lib/mysql файлы вручную. Там находятся таблицы, InnoDB-файлы, redo/undo-данные, binary logs и другие компоненты рабочей базы.

Как определить крупнейшие базы и таблицы?

SELECT
    table_schema AS database_name,
    table_name,
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
ORDER BY (data_length + index_length) DESC
LIMIT 20;

Запрос показывает самые крупные таблицы по данным и индексам. Для WordPress среди них могут оказаться стандартные таблицы, WooCommerce, security-логи, статистика, очереди или таблицы расширений, которые уже давно удалены.

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

Когда проблема в MySQL binary logs?

Сначала проверьте, включён ли binary logging:

SHOW VARIABLES LIKE 'log_bin';

Если включён, список файлов покажет:

SHOW BINARY LOGS;

На версиях MySQL, где используется соответствующий параметр, срок хранения можно проверить так:

SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

В MariaDB и разных версиях MySQL название и логика параметров могут отличаться, поэтому сверяйте текущую конфигурацию конкретного сервера.

Старые binlogs удаляются штатными средствами базы, например через PURGE BINARY LOGS, а не через rm в файловой системе. Но выполнять purge вслепую нельзя: binlogs могут быть нужны для репликации или point-in-time recovery.

Почему удаление данных из таблицы не всегда уменьшает файл?

Удаление строк освобождает место для повторного использования внутри таблицы, но физический файл на диске может остаться прежнего размера. Это зависит от InnoDB, innodb_file_per_table, структуры таблицы и конкретной операции.

Поэтому здесь нужно различать четыре сценария:

• большая таблица с действительно нужными данными;
• таблица, из которой удалили данные, но файл физически не уменьшился;
• накопившиеся binary logs;
• общие InnoDB-файлы и служебные данные.

После любых штатных операций сравнивайте не только данные в MySQL, но и:

du -sh /var/lib/mysql
df -h

Как проверить Docker, если /var/lib неожиданно оказался самым большим каталогом?

Если внутри /var/lib лидирует /var/lib/docker, размер WordPress уже мало что говорит о занятом диске. Docker отдельно хранит images, stopped containers, writable layers, volumes, build cache и контейнерные логи.

Начните с:

docker system df
docker system df -v

В выводе смотрите Images, Containers, Local Volumes и Build Cache. Большое значение RECLAIMABLE подсказывает, где потенциально есть ненужные объекты, но не означает, что всё можно безопасно удалить одной командой.

docker ps -a
docker images
docker volume ls

Почему Docker volume нельзя считать обычным кэшем?

Volume может содержать рабочую MySQL/PostgreSQL-базу, пользовательские файлы или состояние приложения. Перед удалением:

docker volume inspect VOLUME_NAME

Затем сопоставьте volume с контейнером и Docker Compose. Удаление неизвестного volume — это уже риск потери данных, а не обычная очистка диска.

Как найти контейнер, который пишет огромный лог?

Для конкретного контейнера Docker может показать путь к текущему лог-файлу:

docker inspect --format='{{.LogPath}}' CONTAINER

Затем проверьте размер найденного файла:

du -h /path/to/container-log

Если лог занимает гигабайты, посмотрите тип logging driver:

docker inspect --format='{{.HostConfig.LogConfig.Type}}' CONTAINER

Путь LogPath и поведение ограничений зависят от logging driver. Для распространённого json-file отсутствие лимитов max-size и max-file способно привести к бесконтрольному росту логов.

Не стоит воспринимать внутренние файлы /var/lib/docker как обычные файлы приложения и редактировать их вручную без необходимости. Управлять контейнерными данными лучше средствами Docker.

Почему изменение Docker logging settings не всегда исправляет старые контейнеры?

Параметры logging driver задаются при создании контейнера. Если вы изменили настройки Docker daemon, уже существующие контейнеры могут продолжить работать со старой конфигурацией до их пересоздания. Поэтому после изменения лимитов проверяйте фактический LogConfig конкретного контейнера.

docker system prune — уже очистка, а не диагностика. Сначала найдите источник. Потом решайте, какие images, containers, cache или volumes действительно не используются.

Почему df показывает полный диск, а du не может найти занятые гигабайты?

Если df и du сильно расходятся, одна из первых проверок — удалённые файлы, которые всё ещё открыты работающими процессами. Для du такого файла уже нет в каталоге, но файловая система продолжает считать его блоки занятыми.

Типичная картина: огромный error.log удалили вручную, имя исчезло, а df -h почти не изменился. Nginx, Apache, PHP или другое приложение продолжает писать в старый файловый дескриптор.

Как найти удалённые, но открытые файлы?

lsof +L1

Дополнительный вариант:

lsof | grep '(deleted)'

Смотрите имя процесса, PID и размер файла. После этого определите сервис:

ps -fp PID
systemctl status SERVICE

Если причина подтверждена, нужен корректный restart или reload сервиса — в зависимости от того, как конкретный процесс переоткрывает файлы.

df -h

Если пропавшие гигабайты принадлежали deleted-open file, после закрытия дескриптора место вернётся.

Что проверить, если lsof +L1 ничего не нашёл?

Не сводите любое расхождение df и du к удалённому логу. Если lsof пустой, проверьте ещё несколько вещей.

1. Запускался ли du с достаточными правами. Если часть каталогов недоступна текущему пользователю, итоговая сумма может быть неполной. Для серверной диагностики такую проверку обычно выполняют от root или через sudo.

2. Есть ли отдельные mount points.

findmnt
df -Th

Монтирование поверх непустого каталога может скрыть лежащие под точкой монтирования файлы от обычного просмотра. Это уже пограничный случай, но при странном расхождении его стоит учитывать.

3. Зарезервированные блоки файловой системы. На ext-файловых системах часть пространства может быть зарезервирована для привилегированных процессов. Поэтому Avail для обычного пользователя и фактическая занятость блоков не всегда совпадают один в один.

4. Snapshots и особенности хранилища. LVM, ZFS и другие схемы хранения могут добавлять собственный слой учёта пространства. Если VPS использует snapshots, thin provisioning или нестандартную файловую систему, обычных df и du иногда недостаточно.

Если df и du не сходятся, дальше удалять файлы наугад бессмысленно. Сначала нужно объяснить разницу.

Что делать, если место съели миллионы мелких файлов, а не большие архивы?

Если df -h показывает свободные гигабайты, а WordPress, PHP или системный сервис не может создать файл и отвечает No space left on device, проверьте inode:

df -i

Файловая система может быть свободна по объёму и полностью исчерпана по inode. Причиной бывают PHP sessions, WordPress cache, mail queue, Maildir, временные файлы, миниатюры, служебные каталоги приложений и неудачные cron-задачи.

Как найти каталог, который использовал больше всего inode?

На системах с GNU du можно идти по дереву почти так же, как при поиске гигабайтов:

du --inodes -x -d1 /
du --inodes -x -d1 /var

Команда показывает количество файловых объектов, а не их объём. Если /var лидирует, переходите глубже:

du --inodes -x -d1 /var
du --inodes -x -d1 /var/lib

Здесь хорошо работает сравнение двух метрик. Каталог может занимать всего несколько сотен мегабайт:

du -sh /path

но при этом содержать огромное число объектов:

du --inodes -s /path

Это уже типичный inode-сценарий.

Команда:

find /path -xdev -type f | wc -l

считает только regular files. Inode расходуются также на каталоги, symlink и другие объекты, поэтому такой find полезен как дополнительная оценка, но не как полный счётчик inode.

На каталогах с миллионами объектов find и даже du могут создавать заметную дисковую нагрузку. Лучше двигаться по дереву постепенно и не запускать несколько тяжёлых обходов всего VPS одновременно.

После безопасной очистки проверьте:

df -i

Если IFree вырос, причина подтверждена. Но очистить миллион session-файлов недостаточно — нужно выяснить, почему они не удалялись автоматически.

Как безопасно освобождать место, не сломав WordPress, MySQL или VPS?

Когда диск заполнен почти полностью, начинают сбоить уже не только сайты: MySQL не создаёт временные файлы, PHP не записывает сессии, панель управления падает на операциях записи, пакетный менеджер не может обновить систему. В этот момент нужен хотя бы небольшой запас свободного места.

Но не любой ценой.

Хороший аварийный кандидат — старый подтверждённо ненужный архив или кэш, который штатно пересоздаётся. Плохой кандидат — первый большой каталог, который попался в du.

С активными логами есть отдельный риск: после rm процесс может продолжить держать удалённый файл открытым. Поэтому после очистки проверяйте:

df -h
lsof +L1

Затем состояние ключевых сервисов:

systemctl status nginx
systemctl status mysql

На MariaDB unit может называться mariadb; название PHP-FPM тоже зависит от версии и дистрибутива. Дополнительно откройте сам сайт, WordPress admin, выполните операцию, требующую записи в базу, и проверьте сервис, который был источником роста.

Удаляйте по одной подтверждённой категории данных. Тогда видно, что именно освободило диск, и проще заметить побочный эффект.

Как сделать так, чтобы VPS снова не заполнился через неделю?

Очистка возвращает свободное место, но не исправляет механизм роста. Если диск заполнил PHP error log, он вырастет снова. Если проблема в локальных бэкапах, новые архивы продолжат появляться. Если Docker пишет неограниченный json-file, через некоторое время всё повторится.

Как проверить logrotate после очистки?

Если диск заполнили обычные текстовые логи, нужно проверить не только наличие файлов в /etc/logrotate.d/, но и то, как logrotate интерпретирует конфигурацию.

logrotate -d /etc/logrotate.conf

Режим -d выполняет debug-проверку и показывает, какие правила будут применяться, без обычной ротации файлов. В выводе смотрите, видит ли logrotate нужный журнал, не пропускается ли он из-за условий по времени или размеру и нет ли ошибок конфигурации.

Как ограничить systemd journal?

Настройки journald находятся в его конфигурации. Среди параметров, которые имеет смысл проверить:

• SystemMaxUse;
• RuntimeMaxUse;
• MaxRetentionSec.

Универсальных значений здесь нет: лимит зависит от размера диска и от того, насколько долго вам нужны системные журналы. После изменения проверяйте:

journalctl --disk-usage

Как ограничить рост Docker logs?

Для logging driver json-file обычно используют ограничения max-size и max-file. После изменения глобальной конфигурации не считайте проблему решённой автоматически: уже созданные контейнеры могут продолжить работать с прежним LogConfig.

Проверьте конкретный контейнер:

docker inspect --format='{{json .HostConfig.LogConfig}}' CONTAINER

Если настройки не изменились, контейнер может потребоваться пересоздать с нужными параметрами. Перед этим, конечно, убедитесь, что постоянные данные вынесены в корректные volumes.

Как проверить, удаляются ли старые резервные копии?

Не ограничивайтесь значением retention в панели. Посмотрите фактическое состояние каталога:

du -sh /path/to/backups
ls -lah /path/to/backups

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

Как контролировать MySQL binary logs?

После настройки expiration периодически проверяйте:

SHOW BINARY LOGS;

и текущую настройку срока хранения, поддерживаемую вашей версией MySQL или MariaDB. Смысл проверки простой: старые binlogs должны реально исчезать согласно политике, а не просто иметь настроенный параметр в конфиге.

После такой аварии имеет смысл поставить предупреждение раньше, чем Avail уйдёт почти в ноль. Порог лучше выбирать не только в процентах: 10% свободного места на дисках разного размера означают совершенно разный реальный запас.

Если рабочие данные действительно занимают весь доступный объём и их рост ожидаемый, тогда уже имеет смысл увеличивать диск. Но это решение принимают после диагностики, а не вместо неё.

Быстрый алгоритм: что проверять, если диск VPS снова показывает 90–100%?

Если проблема повторится, идти лучше по одному и тому же маршруту. Шаги, которые не относятся к конфигурации конкретного VPS, можно пропускать.

1. Проверить разделы. Выполнить df -h и определить файловую систему с высоким Use%.
2. Проверить inode. Выполнить df -i и посмотреть IUse%.
3. Найти крупный верхнеуровневый каталог. Использовать du -xhd1 /.
4. Углубиться в найденный путь. Например, du -xhd1 /var, затем /var/lib или /var/log.
5. Проверить журналы. Посмотреть крупные файлы в /var/log и выполнить journalctl --disk-usage.
6. Проверить кэш и PHP sessions. Найти реальные cache paths и session.save_path, а не очищать каталоги по названию.
7. Найти старые архивы и SQL dumps. Проверить все нужные файловые системы, помня про ограничение -xdev.
8. Если велик /var/lib/mysql. Анализировать таблицы и binlogs через MySQL/MariaDB. Не удалять файлы вручную.
9. Если велик /var/lib/docker. Начать с docker system df, затем проверить volumes и LogPath контейнеров.
10. Если df и du заметно расходятся. Выполнить lsof +L1; если ничего нет — проверить права, mounts и особенности файловой системы.
11. Если закончились inode. Использовать du --inodes и локализовать каталог с огромным количеством объектов.
12. Освободить небольшой запас места. Удалять только подтверждённо ненужные данные.
13. Проверить результат. Повторить df -h, df -i при необходимости и проверить затронутые сервисы.
14. Остановить повторный рост. Настроить log rotation, journald limits, backup retention, Docker logging limits, cache TTL или binlog expiration.

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

Если причина нашлась на первых шагах — дальше идти не нужно. Если цифры не сходятся, не компенсируйте это массовым удалением. Сначала объясните расхождение метрик, потом чистите сервер. Именно такой порядок обычно отличает безопасную диагностику от ситуации, когда место вроде освободили, а вместе с ним исчезли нужные данные.