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

Коротке зміст

Discourse – популярна платформа для онлайн‑обговорень, на якій зараз понад 22 000 спільнот.

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

Нижче – докладний розбір ситуації, причин та рішень.

1. Що сталося?
ЕлементДаніПлатформаDiscourseКількість спільнот>22 000Файл‑проблемаGIF «Рейчел з «Друзів»», розмір 1,6 МБКількість копій246 173 (жорсткі посилання)Ліміт ext4~65 000 жорстких посилань на один inodeЗагальний розмір бекапу377 ГБ
Чому це сталося?
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 у своєму блозі.