Linux: full disk and growing an LVM volume

3:12 in the morning. The on-call phone rings: not a single invoice is going out, the /srv/factures volume is at 100%. You must restore the service tonight, without rebooting the server, without making /etc/fstab invalid, and without deleting anything that has accounting value. In the morning, management will ask one question only: why was nobody warned before the outage? “Disk full” covers three different failures, and they are not treated the same way. The guide makes you diagnose before you touch: you predict what df and du will answer, and their disagreement leads you to a file deleted the day before but still held open by a service, which still takes up hundreds of megabytes. You give that space back without erasing a single file, then you grow the logical volume and its file system online, without unmounting and without interrupting invoicing. The lab then goes where tutorials stop. Deciding whether swap is a cure or a symptom by reading real memory usage, rather than following a ready-made rule. Then setting up what was really missing: a measurement of how full the disk is, scheduled by a systemd timer, and a CloudWatch alarm with a threshold that leaves time to act during the day. At the end, the machine's state and the alarm are checked, and the result counts for your ranking. A real server, in incident conditions.