Архив сайта и папка .git в корне: как любой скачает вашу базу и пароли за тридцать секунд

Архив сайта, оставленный в корне «на всякий случай», веб-сервер отдаёт по прямому адресу так же спокойно, как логотип в шапке: для него это обычный файл, а не секрет. Внутри такого архива лежит весь сайт вместе с конфигурационным файлом, а рядом с ним обычно обнаруживается дамп базы — с телефонами клиентов, текстами заявок и хэшами паролей администраторов. Владелец при этом не видит ничего: сайт открывается, счётчик показывает те же цифры, в админке тишина. Никакого взлома тут и не требуется — файл просто лежит и отдаётся всем, кто обратится по его адресу.

Ниже — механика этой выдачи, перечень объектов, которых в корне быть не должно, порядок осмотра своего корня через панель хостинга, правила запрета для Apache и nginx с оговоркой про сертификаты, план замены секретов, если файл лежал открытым, и срок реакции, который задаёт закон о персональных данных. В SEO с 2005 года, и корень сайта я открываю раньше отчётов по позициям: причина странных вещей в выдаче чаще находится там.

Почему сервер отдаёт архив так же охотно, как картинку

Корень сайта, он же docroot, — это каталог, содержимое которого веб-сервер публикует по прямым адресам. Механика простая: пришёл запрос на адрес, сервер сопоставил его с путём внутри каталога, нашёл файл, отдал с кодом ответа 200. Никакой отдельной логики для «важных» файлов в этой схеме нет. Логотип, PDF с прайсом и архив со всем сайтом обрабатываются одинаково: если файл лежит в корне и ни одно правило его не закрывает, он выдаётся по запросу целиком.

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

• Имена типовые. Копии называют не случайными наборами символов, а понятными словами, чтобы потом самому разобраться. Именно предсказуемость имени и делает файл находимым.
• Адрес утекает через ссылки. Стоит один раз отправить ссылку на архив в мессенджере, по почте или в тикете хостеру — адрес выходит за пределы вашей головы и остаётся в чужих переписках.
• Адрес попадает в журналы и в индекс. Если на файл где-то есть ссылка, поисковый робот по ней придёт: для него это обычный документ. Дамп базы в результатах поиска по своему же сайту — не редкость, а закономерный итог.
• Каталоги умеют показывать список. При включённом автоиндексе сервер сам выводит содержимое папки, и угадывать уже нечего.

Второе заблуждение — закрыть файл через robots.txt. Этот файл адресован поисковым роботам и содержит просьбу не индексировать, а не запрет на выдачу. Сервер после такой записи отдаёт файл ровно так же, как раньше. Более того, перечисление секретных путей в общедоступном robots.txt превращает его в оглавление: строка с именем архива видна любому, кто откроет этот файл, а открыть его может кто угодно.

Одиннадцать объектов в корне, которых там быть не должно

Ниже — то, что я нахожу в корнях чаще всего. Колонка «как попадает» здесь важнее остальных: почти всегда это след обычной рабочей операции, а не чьего-то злого умысла.

Объект в корне	Как он туда попадает	Что внутри и чем опасно
backup.zip, site.tar.gz, old.zip	«сделаю копию перед правкой»	весь сайт целиком вместе с конфигурационными файлами
dump.sql, db.sql, base.sql	выгрузка базы для разработчика или переноса	все данные: заявки, телефоны, адреса, хэши паролей пользователей
wp-config.php.bak, wp-config.old, wp-config.php~	правка файла через встроенный редактор панели	логин и пароль базы, ключи и соли — в виде обычного текста
каталог .git/	деплой командой обновления репозитория прямо в корень	история изменений и всё, что когда-либо в репозиторий попадало
каталог .svn/	наследие старой схемы выкладки	то же: служебные данные и прежние версии файлов
.env	перенос кода, написанного на фреймворке	пароль базы, ключи платёжных и почтовых сервисов, токены
phpinfo.php, info.php	разовая диагностика «а какая тут версия PHP»	полная конфигурация сервера: пути, модули, переменные окружения
adminer.php, сторонние файловые менеджеры	«чтобы быстро залезть в базу без панели»	готовая точка входа в базу и в файлы, минуя все журналы
error_log, debug.log	включённая и забытая отладка	пути на диске, тексты запросов, иногда фрагменты данных
.DS_Store, Thumbs.db	загрузка папки с компьютера целиком	перечень файлов каталога, включая те, что не видны иначе
каталоги .idea/, .vscode/	загрузка папки проекта вместе со служебными файлами	настройки проекта, пути, иногда сохранённые доступы к серверу

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

Как эти файлы там оказываются: четыре обычных сценария

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

Сценарий второй — передача подрядчику. Разработчику нужна база. Выгрузка кладётся в корень, ссылка отправляется в мессенджер: «скачай». Подрядчик скачал, работа сделана, файл никто не убрал. Хуже того, ссылка осталась в переписке и в истории браузера у обеих сторон.

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

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

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

Что лежит внутри wp-config.php и почему его копия хуже дампа

Сам wp-config.php в корне лежать обязан — без него сайт не работает. При запросе его адреса PHP файл исполняет, а в браузер уходит пустая страница: содержимое наружу не попадает. Ровно поэтому пароль базы в нём хранить нормально.

Ломается это одним движением — сменой расширения. Файл wp-config.php.bak для сервера не программа, а текстовый документ, и он отдаётся как есть, вместе со всем содержимым. То же с .old, .txt, .save и тильдой на конце имени.

Что в файле	Что это даёт	Что делать, если копия была открыта
DB_NAME, DB_USER, DB_PASSWORD, DB_HOST	доступ к базе, если сервер базы принимает внешние подключения	сменить пароль базы в панели хостинга и вписать новый в конфиг
Префикс таблиц	знание структуры базы вашего сайта	менять не нужно, на защиту он не влияет
AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY и соли к ним	возможность подделать активную сессию администратора без пароля	заменить весь набор новым, старые значения считать недействительными
Ключи внешних сервисов, если их дописывали в конфиг	доступ к почте, платежам, сторонним API от вашего имени	перевыпустить каждый ключ в кабинете соответствующего сервиса
Строка с включённой отладкой	подсказку, что на сайте есть читаемый файл журнала	отладку выключить, файл журнала удалить

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

Новый набор WordPress выдаёт по своему официальному адресу генератора — api.wordpress.org/secret-key/1.1/salt/. Готовый блок вставляется в конфиг вместо старого. Побочный эффект — все сессии на сайте становятся недействительными, и всем придётся войти заново. После утечки это не побочный эффект, а цель.

Папка .git в корне: что она содержит и почему её нельзя держать в docroot

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

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

Отсюда несколько практических следствий.

• .gitignore от веб-доступа не защищает вообще. Он решает другую задачу — какие файлы не брать в репозиторий. К тому, что сервер отдаёт наружу, он не имеет отношения. Это самая устойчивая путаница по теме.
• Каталог с точкой не виден по умолчанию. Файловые менеджеры панелей и FTP-клиенты скрывают такие имена, пока не включишь показ скрытых файлов. Владелец смотрит на корень и .git не видит — а сервер его видит.
• Пароль, который когда-то был в репозитории, надо считать известным. Даже если каталог уже убран: проверить по журналам, скачивал ли его кто-то, обычно нельзя — записи за давние даты у большинства хостеров не хранятся.
• С .svn и служебными каталогами других систем всё то же самое. Схема выкладки старая, а последствия одинаковые.

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

Открытый листинг каталогов: как проверить у себя и отключить

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

Проверяется на своём сайте за минуту: открыть в браузере адрес любой папки, где нет index.php или index.html, — например каталога с документами или загрузками. Увидели список файлов с размерами и датами — автоиндекс включён. Получили 403 или страницу «не найдено» — выключен.

Отключается в конфигурации: на Apache директивой Options -Indexes в .htaccess в корне, на nginx — параметром autoindex off в настройках сайта (в большинстве сборок это значение по умолчанию, но его переключают в панели, забывают и не возвращают).

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

Как за десять минут осмотреть свой корень

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

1. Включить показ скрытых файлов. В файловых менеджерах это отдельная галочка в настройках вида, в FTP-клиентах — пункт меню. Без неё каталоги, начинающиеся с точки, не видны, а именно они в этой теме самые неприятные.
2. Отсортировать список по размеру. Архивы и дампы всегда на порядки крупнее остальных файлов корня. Первая строка при сортировке по убыванию — самое быстрое, что можно сделать.
3. Отсортировать по дате изменения. Посторонние файлы появляются в дни переносов, правок и подключения подрядчиков. Скопление файлов одной датой — повод вспомнить, что тогда делали.
4. Сверить состав корня с ожидаемым. Для WordPress это index.php, wp-config.php, wp-load.php, wp-settings.php, wp-cron.php, файлы административного входа, .htaccess на Apache и три каталога — wp-admin, wp-includes, wp-content. Плюс иногда robots.txt, карта сайта и файлы подтверждения прав в панелях вебмастеров. Всё остальное требует объяснения: кто положил, зачем и можно ли убрать.
5. Заглянуть в подкаталоги, где по смыслу не должно быть кода. Загрузки, кэш, каталог с документами. Архивы и PHP-файлы там — отдельный разговор.
6. Записать находки списком, а не удалять сразу. Часть файлов может быть нужна работающему сайту. Правильный порядок: перенести за пределы корня, убедиться, что сайт жив, и только потом удалять.

Осмотр корня — один из пунктов общей технической проверки; остальные я собрал в чек-листе проверки сайта, чтобы не держать их в голове. Занимает всё вместе вечер, повторять достаточно раз в квартал.

Проверка кодов ответа и поиск лишнего в индексе

После уборки нужно убедиться, что сервер отвечает правильно. Проверяют это по своим адресам, и смотреть нужно не на картинку в браузере, а на код ответа: пустая страница может оказаться и ошибкой с кодом 200.

Что проверяем на своём сайте	Правильный ответ	Что значит код 200
Адрес удалённого архива или дампа	404 или 403	файл на месте или правило не работает
Адрес внутри служебного каталога репозитория	403 или 404	каталог доступен наружу
Адрес папки без индексного файла	403	включён автоиндекс
Адрес копии конфигурационного файла	404	содержимое отдаётся как текст
Адрес файла проверки сертификата в каталоге .well-known	200	всё в порядке: этот адрес должен работать

Последняя строка — не исключение ради полноты, а напоминание: правило «запретить всё, что начинается с точки» ломает продление сертификатов. Об этом подробно в следующем разделе.

Дальше — индекс. В Яндекс Вебмастере раздел «Индексирование → Страницы в поиске» показывает, что попало в поиск; конкретный адрес своего сайта проверяют оператором url:. Если лишний файл в индексе, там же, в панели, есть инструмент удаления страниц из поиска — и работает он только для сайтов, права на которые подтверждены, то есть исключительно для своих. Одновременно стоит убедиться, что содержимое сайта не размножилось по другим доменам: как это проверять, я разбирал в материале про то, что делать, если сайт клонировали на другом домене.

И журналы. Журнал доступа за период, пока файл лежал открытым, есть в панели у большинства хостингов. Ищем в нём обращения к имени этого файла: были ли, сколько, с каких адресов, каким был код ответа и объём отданных данных. Это единственный способ ответить на вопрос «скачали или нет» фактами, а не догадками. Срок хранения журналов ограничен — обычно неделями, — поэтому смотреть надо сразу, а не когда будет время.

Правила для Apache и nginx, и ловушка с продлением сертификата

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

На Apache всё делается в .htaccess в корне. Запрет на пути, начинающиеся с точки: RedirectMatch 404 ^/\.(git|svn|env|idea|vscode). Запрет на выдачу архивов, дампов и резервных копий — блоком <FilesMatch "\.(sql|zip|tar|gz|tgz|bak|old|log|env|swp)$"> с директивой Require all denied внутри; на старых версиях сервера вместо неё пишут Order allow,deny и Deny from all. Плюс Options -Indexes той же правкой.

На nginx это блоки в конфигурации сайта: location ~ /\.(?!well-known) { deny all; } для точечных путей и location ~* \.(sql|zip|tar|gz|bak|old|log|env)$ { deny all; } для архивов и дампов.

Теперь про исключение (?!well-known), из-за которого ломаются сайты. Каталог /.well-known/acme-challenge/ тоже начинается с точки, а через него центр сертификации проверяет, что домен ваш. Закрыли все точечные пути без исключения — проверка перестала проходить, и очередное автоматическое продление не состоялось. Сайт при этом работает как обычно, ровно до дня, когда срок сертификата кончится, и браузеры начнут показывать предупреждение. Отсюда практический вывод: исключение для этого каталога обязательно, а срок действия сертификата стоит держать под присмотром — механика продления описана в разборе про бесплатный SSL-сертификат.

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

Если файл лежал открытым: что менять и в каком порядке

Исходная установка — файл скачали. Доказать обратное журналами удаётся не всегда, а действовать из предположения «наверное, не заметили» дороже, чем один вечер работы. Порядок важен: сначала закрыть источник, потом обесценить то, что утекло.

1. Убрать файл из корня. Резервные копии — за пределы docroot, к хостеру или в отдельное хранилище. Диагностические скрипты и файловые менеджеры — удалить.
2. Поставить правила запрета и проверить их по кодам ответа, как описано выше.
3. Сменить пароли доступа. Пароль базы в панели хостинга и в конфигурационном файле, пароли FTP и SSH, пароль ящика, от которого сайт отправляет письма, пароли всех администраторов сайта. Заодно посмотреть, сколько вообще администраторов и кому какие доступы выданы: разбор по ролям я собрал в материале про доступы к сайту.
4. Заменить ключи и соли в конфигурационном файле. Это обнуляет украденные сессии. Всех разлогинит, включая вас, — так и должно быть.
5. Проверить список пользователей и журнал входов. Лишний администратор, созданный после даты утечки, — прямой признак, что доступом воспользовались. Что именно смотреть в журнале и какие настройки входа отключить, я описывал в материале про журнал входов в админку.
6. Просмотреть задания планировщика и файлы с датой изменения после утечки. Задание, которое восстанавливает удалённый код, — обычный способ закрепиться надолго.
7. Проверить почту. Если утёк пароль ящика, с него могли рассылать. Последствие — падение репутации адреса, и дальше уже письма с заявками начинают теряться: механика и починка — в разборе, почему письма с сайта уходят в спам.
8. Оценить состав данных. Что именно было в дампе: только контент и настройки или ещё и персональные данные клиентов. От ответа зависит, техническая это история или ещё и юридическая.

Персональные данные в дампе: сутки на уведомление

Если в открытом дампе были имена, телефоны, адреса почты или тексты заявок клиентов, вступает в силу Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных». Владелец сайта, собирающего заявки, для этого закона — оператор персональных данных, со всеми обязанностями.

Норма	О чём она	Что это значит на практике
Ч. 3.1 ст. 21 (введена Федеральным законом от 14.07.2022 № 266-ФЗ)	уведомление уполномоченного органа при неправомерной передаче данных	24 часа на сообщение о факте и 72 часа на результаты внутреннего расследования
Ст. 18.1	обязанность принимать меры для соблюдения закона	наличие внутренних правил и понятного порядка действий — тоже требование
Ст. 19	организационные и технические меры защиты данных	открытый дамп в корне — прямое расхождение с этим требованием
Ст. 13.11 КоАП РФ	ответственность за нарушения в области персональных данных	составы и размеры менялись — сверяйте с действующей редакцией на дату события

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

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

Как больше не наступать: правила деплоя и резервных копий

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

Где лежит копия	Доступна ли из веба	Когда подходит
В корне сайта	да, по прямому адресу	никогда
В подкаталоге корня с «непонятным» именем	да, защиты нет — только надежда на имя	никогда
Выше корня, в домашнем каталоге на сервере	нет	для быстрого отката перед правкой
Штатные копии у хостера	нет	основной вариант, но проверьте глубину хранения
Отдельное хранилище или свой компьютер	нет	для копий, которые должны выжить вместе с аккаунтом хостинга

Остальные правила короткие, но каждое закрывает свой сценарий из тех четырёх.

• Деплой — так, чтобы служебный каталог не лежал в корне. Либо выкладка экспортом файлов, либо корнем назначен подкаталог проекта.
• Конфигурационные файлы править локально. Скачать, поправить, загрузить обратно поверх — вместо «сохранить копию рядом».
• Отладку включать на время и выключать сразу. В WordPress при define( 'WP_DEBUG_LOG', true ); журнал по умолчанию пишется в wp-content/debug.log — файл читаемый, и он остаётся на сайте, пока его не удалят.
• Разовые скрипты удалять в тот же день. Файл диагностики живёт ровно столько, сколько нужно на диагностику.
• Права доступа — по документации. Официальная рекомендация WordPress в разделе «Changing File Permissions» — 644 на файлы и 755 на каталоги, а для конфигурационного файла права ставят строже.
• Раз в квартал — глазами по корню. Пять минут по описанному выше порядку. Этого достаточно, чтобы архив не пролежал год.

Про влияние на позиции скажу без преувеличений: прямой связи между открытым архивом в корне и местами в выдаче нет, поисковые системы за это не наказывают. Связь появляется через последствия — дамп в индексе, взлом с генерацией спам-страниц, копия сайта на чужом домене, письма с вашего адреса в спаме после утечки доступов к почте. Именно поэтому технический осмотр у меня стоит первым этапом, а не «когда дойдёт очередь»: продвижение сайта в Яндексе с аудитом безопасности начинается с того, что сайт перестаёт отдавать наружу лишнее, и только потом имеет смысл вкладываться в страницы и запросы. Если хочется понять, есть ли у вас такие находки, начните с бесплатного аудита сайта — состав корня там смотрится в первую очередь.

Коротко

• Корень сайта — публичный каталог. Архив, дамп и служебная папка отдаются по прямому адресу с кодом 200 так же, как картинка: отдельной логики для «важных» файлов у сервера нет.
• «Имя никто не угадает» защитой не является: имена типовые, адреса утекают в переписки и журналы, при включённом автоиндексе список файлов виден целиком.
• robots.txt ничего не закрывает, а перечисление секретных путей в нём делает его оглавлением.
• Копия конфигурационного файла опаснее дампа: сам wp-config.php исполняется и наружу не выдаётся, а wp-config.php.bak отдаётся текстом вместе с паролем базы, ключами и солями.
• Каталог .git хранит всю историю, включая файлы, удалённые год назад. .gitignore от веб-доступа не защищает — это про содержимое репозитория, а не про выдачу сервером.
• Осмотр корня: включить показ скрытых файлов, отсортировать по размеру и дате, сверить состав с ожидаемым, находки сначала перенести, потом удалять.
• Проверять надо код ответа по своим адресам: нужен 403 или 404, а не 200. Лишнее в индексе видно в Яндекс Вебмастере, и удалять его оттуда можно только для подтверждённого сайта.
• Правила: на Apache — запрет точечных путей, блок по расширениям архивов и Options -Indexes; на nginx — те же два блока с deny all. Правило это вторая линия, первая — отсутствие файла.
• Исключение для .well-known обязательно, иначе ломается автоматическое продление сертификата. Ручные правки конфигурации панель хостинга перезаписывает — проверять после каждого действия в панели.
• После утечки порядок такой: убрать файл, поставить правила, сменить все пароли, заменить ключи и соли, проверить администраторов и журнал входов, планировщик, почту, состав данных.
• Персональные данные в дампе — это ещё и 152-ФЗ от 27.07.2006: ч. 3.1 ст. 21 даёт 24 часа на уведомление о факте и 72 часа на результаты расследования; ответственность — ст. 13.11 КоАП РФ, сверяйте с действующей редакцией.
• Профилактика: копии вне корня, деплой без служебного каталога в docroot, правка конфигов локально, отладка только на время, разовые скрипты удалять сразу, осмотр корня раз в квартал.