Старые UNIX-серверы конца 1980-х и 1990-х годов до сих пор хранят странные файлы, которые вызывают вопросы даже у опытных специалистов. Это не вирусы и не ошибки системы - чаще всего это остатки старых программ, служебные данные и экспериментальные файлы, о назначении которых мало кто помнит.
При миграции старого банковского сервера, которому было лет двадцать пять, обнаружили файл с именем ".mystery" размером несколько мегабайт в корневой директории. Внутри оказались бинарные данные вперемешку с ASCII-текстом на английском. Поиски в документации, консультации с коллегами, попытки найти упоминания в интернете - всё безрезультатно. Файл лежал там с 1997 года, назначение его оставалось загадкой. Команда решила не рисковать удалением - вдруг система использует его для каких-то критичных операций? Файл благополучно мигрировал на новое оборудование вместе со всеми остальными данными. Подобных артефактов на старых UNIX-системах полно, и у каждого своя история.
Файлы-призраки: core dumps и забытые дампы
Core dump - это снимок памяти программы в момент её краха. Когда приложение падало с ошибкой, UNIX создавал файл core в текущей директории. Программисты использовали эти дампы для отладки, чтобы понять, что пошло не так.
Проблема в том, что на серверах, работавших годами, таких файлов накапливались сотни. Каждый весил от нескольких мегабайт до гигабайта. Программист смотрел дамп, находил баг, исправлял - а файл оставался лежать. Через месяцы и годы сервер превращался в свалку забытых core dumps.
Почему не удаляли? Потому что системные администраторы часто боялись трогать неизвестное. Удалишь что-то важное - система упадёт, а виноват ты. Проще оставить как есть, диск ещё не переполнен. Вот так артефакты и накапливались десятилетиями.
«В старых UNIX-системах каждый файл - потенциальная капсула времени. Только вот часто непонятно, что в этой капсуле и зачем её вообще закопали».
Скрытые файлы с точками: служебные и не очень
В UNIX файлы, начинающиеся с точки, скрыты от обычного просмотра. Это традиция для конфигурационных файлов: .bashrc, .profile, .ssh. Но на старых серверах встречаются файлы с названиями типа .hidden, .old, .backup, .temp - и никто не помнит, что там.
Находили файл .dont_touch в домашней директории пользователя, который уволился лет пятнадцать назад. Внутри - скрипт на Shell с комментариями на ломаном английском. Скрипт что-то делал с базой данных, судя по коду. Работает ли он? Используется ли? Можно ли удалить? Непонятно.
Ещё классика - файлы .nfs* с хаотичными цифрами в имени. Это остатки сетевой файловой системы NFS. Когда файл удаляется, но ещё открыт программой на удалённом компьютере, NFS создаёт временный файл с таким названием. После закрытия файл должен исчезнуть автоматически, но иногда система глючила, и файлы оставались навечно.
Экспериментальные файлы и тестовые данные
Программисты и администраторы часто создавали тестовые файлы для экспериментов. test.txt, data.bin, output.log - и забывали удалить. На промышленных серверах такие файлы смешивались с реальными данными.
Бывало ещё хуже: кто-то запускал скрипт генерации тестовых данных и забывал его остановить. Скрипт писал в файл несколько дней, создав многогигабайтный мусор. Потом автор понял, что лажанулся, убил процесс, но файл оставил - вдруг пригодится для анализа. Конечно, не пригодился.
Или файлы типа junk, trash, delete_me, old_stuff - названия говорящие, но никто не удалял. Потому что неизвестно, насколько это действительно мусор. Может, там критичные данные, просто названные неудачно? Администраторы перестраховывались.
Остатки удалённого софта
Программы в UNIX устанавливались не так аккуратно, как сейчас. Часто файлы разбрасывались по системе: в /usr/local, /opt, /var, домашних директориях. При удалении программы не все файлы убирались - оставались конфиги, логи, кеши, временные данные.
Классический пример - остатки старых версий баз данных. Обновили MySQL с версии 3 на версию 4, но файлы старой версии остались в /var/lib/mysql.old. Потом обновились до версии 5 - появилась ещё одна папка с архивом. Через десять лет на сервере три копии старых данных, которые никто не использует, но все боятся удалить.
Или библиотеки - .so файлы в /usr/lib. Программа удалена, но библиотеки остались, потому что системный менеджер пакетов не был уверен, что их больше никто не использует. За годы накапливались десятки устаревших библиотек, дублирующих друг друга.
Находили на серверах целые директории типа /usr/local/oldapps или /opt/legacy с программами, которые не запускались лет десять. Но никто не решался удалить - а вдруг там что-то важное? А вдруг какой-то скрипт на них ссылается? Безопаснее оставить.
«Старые серверы - как чердаки бабушкиных домов. Вроде всё это мусор, но вдруг пригодится, и выбросить страшно».
Документация и README, которые никто не читал
Текстовые файлы с инструкциями, объяснениями, предупреждениями - их создавали с благими намерениями, но читали редко. README, INSTALL, CHANGELOG, TODO - файлы, которые должны были помочь будущим поколениям администраторов.
Бывали и курьёзы. Находили файл PLEASE_READ_THIS.txt с текстом: "Don't delete files in this directory, system will crash" - «Не удаляйте файлы в этой директории, система упадёт». Директория содержала какие-то бинарные файлы непонятного назначения. Удалить страшно, оставить непонятно зачем. Текущий администратор не знает, кто написал предупреждение и насколько оно актуально.
Логи, которые никто не ротировал
Файлы логов - отдельная песня. Программы писали логи в /var/log или /tmp, и если не настроена ротация (автоматическая очистка старых логов), файлы росли бесконечно.
Или логи с названиями debug.log, trace.log - их создавали для отладки проблемы, потом проблему решили, но логирование не отключили. Годами файл рос, записывая ненужную информацию.
Были случаи, когда старые логи содержали ценную историческую информацию. Восстанавливали хронологию событий при расследовании инцидента - и находили следы в логах десятилетней давности. Но чаще логи просто занимали место.
Зачем это всё хранили
Причин несколько. Первая - страх что-то сломать. Администраторы работали по принципу "If it ain't broken, don't fix it" - работает, не трогай. Неизвестный файл - потенциальный риск при удалении.
Вторая причина - нехватка времени. Разбираться, что за файл, зачем он нужен, можно ли удалить - это работа. А текущих задач и так полно. Проще оставить как есть, пока место на диске не закончится.
Третья - недостаточная документация. Систему настраивал один человек, потом он ушёл, документацию не оставил. Новый администратор видит странные файлы, но не знает их назначения. Удалять опасно, спросить не у кого.
Что с этим делать сейчас
Если работаете со старым UNIX-сервером, вот практические советы:
Не удаляйте файлы вслепую. Даже если файл кажется мусором, проверьте: когда последний раз к нему обращались, связан ли он с работающими процессами, есть ли на него ссылки в конфигурациях.
Делайте бэкапы перед чисткой. Удалили что-то важное? Можно вернуть. Без бэкапа рискуете положить систему.
Изучайте историю системы. Старые логи, README-файлы, комментарии в скриптах - там может быть информация о назначении загадочных файлов.
Консультируйтесь с теми, кто работал раньше. Если есть возможность связаться с бывшими администраторами.
Архивируйте, а не удаляйте. Сомневаетесь, нужен ли файл? Переместите его в архивную директорию, сожмите, оставьте на полгода. Если за это время ничего не сломалось - можно удалить окончательно.
Миграция старых систем - всегда квест. Разбираешься в артефактах прошлого, пытаешься понять логику людей, работавших двадцать лет назад. Иногда находишь интересные вещи, иногда просто мусор. Но каждый файл - кусочек истории.
Загадочные файлы на старых UNIX-серверах - это археология IT. Каждый файл когда-то создавался с целью, но цель забылась, а файл остался. Программисты ушли, компании закрылись, технологии устарели, а данные продолжают лежать на дисках.
Это напоминает, что технологии создаются людьми. За каждым test.txt или .mystery стоит человек, который когда-то решал задачу, экспериментировал, учился. Файл остался как след этой деятельности.
Может, через двадцать лет кто-то найдёт ваши временные файлы и тоже будет гадать: зачем это создали и почему не удалили? История повторяется, только технологии меняются. А привычка оставлять за собой цифровой мусор - вечна.
📖 Читайте также:
→ Почему в NASA до сих пор есть строка кода, которую запрещено трогать?
→ Спам или загадка? Markovian Parallax Denigrate взрывает мозг
→ Забытые языки программирования