GIF‑клип с танцем Рейчел из «Друзей» вырос в сотни гигабайт, обрушив резервные копии Discourse

Краткое содержание

Discourse – популярная платформа для онлайн‑обсуждений, на которой сейчас более 22 000 сообществ.
Недавно при резервном копировании сайта возникла критическая проблема: один GIF‑файл (1,6 МБ) был скопирован пользователями 246 173 раза, что превысило лимит жёстких ссылок в файловой системе ext4 и привело к росту размера бэкапа до 377 ГБ.

Ниже – подробный разбор ситуации, причин и решений.

1. Что произошло?

Почему так случилось?

Discourse позволяет вставлять эмодзи и GIF‑файлы в любые сообщения.
При перемещении файла из одного контекста в другой (например, из личного чата в публичный пост) система создаёт новую копию с случайным SHA‑1 хешем. Это означает, что даже если содержимое идентично, Discourse рассматривает его как новый объект.

Таким образом, один GIF может появиться в десятках тысяч сообщений и личных чатах – каждый раз генерируется отдельный файл. В итоге 246 173 копий превысили лимит ext4, и система начала создавать новые файлы вместо жёстких ссылок, что привело к «потери» 181 000 резервных копий.

2. Первое решение – хеш‑сборка

Discourse сначала попытался решить проблему, группируя загрузки по SHA‑1:

1. При бэкапировании все файлы собирались в группы одинакового хеша.
2. Загружалась только первая копия из каждой группы.
3. Для остальных создавались жёсткие ссылки.

Это выглядело элегантно – но не учитывало ограничение ext4 на количество ссылок. Как только лимит был достигнут, система автоматически создавала новые файлы вместо ссылок, и размер бэкапа резко вырос.

3. Новое решение – «переход» при ошибке EMLINK

Discourse разработал более гибкую стратегию:

1. Создаётся жёсткая ссылка на файл, как обычно.
2. Если файловая система возвращает ошибку EMLINK (превышен лимит ссылок), следующая копия становится «основной» файлом.
3. С этого момента новые ссылки снова создаются к этой новой основной версии.

Таким образом, при каждом превышении лимита происходит переключение на новый “родительский” файл, и система продолжает работать без ошибок. Это решение совместимо с любой файловой системой и не требует дополнительной настройки.

4. Итоги и выводы

- Один популярный GIF (танец Рейчел из «Друзья») стал причиной роста резервного копирования до 377 ГБ.
- Ограничение ext4 на ~65 000 жёстких ссылок оказалось критическим фактором.
- Первое решение с хеш‑сборкой не учло файловые ограничения, что привело к потере данных.
- Новая стратегия «перехода» при ошибке EMLINK позволяет корректно управлять большим количеством копий и сохранять эффективность резервного копирования.

> *“Теперь мы знаем, что Дженнифер Энистон может проводить стресс‑тестирование инфраструктуры,”* — с иронией отметила Discourse в своём блоге.