System Data grew 50 GB overnight: what happened

Part of: System Data on Mac: what is inside and how to reduce it safely (System Data)

A big sudden jump in System Data feels alarming, but it nearly always has one clear cause. If you want the general picture first, read the System Data guide. The trick is to look at what changed recently, not at everything. These checks only read, they change nothing.

Think about what happened last

Ask three quick questions before running anything:

1. Did macOS update or download an update recently?
2. Did you install, open or sync something big, such as a cloud folder or a game?
3. Did an app misbehave, crash or hang?

Any “yes” points you to the right step below.

Check 1: Large new files

Find big files changed in the last two days under your home folder:

find ~ -type f -size +1G -mtime -2 2>/dev/null

This prints files over 1 GB changed in the last two days. If it prints nothing, no single large file explains the jump. If it prints files, it shows whether one of them does. Be careful reading the result: the files you see may belong to apps and may not be yours to delete.

If a huge file is a log or crash dump from an app, the app is the real problem. Quit it, clear that file, and look at its settings or update.

Check 2: Local snapshots

tmutil listlocalsnapshots /

A snapshot made around an update or a backup can hold a lot of changed data. See the local snapshots guide. macOS releases it when it needs room.

Check 3: Swap and memory pressure

When memory is full, macOS uses the disk. Check how much:

sysctl vm.swapusage

On a quiet Mac this usually shows little or no swap in use. A figure of many gigabytes means a heavy workload, and closing the memory-hungry apps and restarting gives the space back.

Find out who owns a large file

If Check 1 lists a file, two read-only commands help. ls -lh followed by the file path shows its size and last change time. lsof followed by the same path lists any process that has the file open right now. If a process is listed, that app is writing it, so quit the app before you decide anything. If nothing is listed, the file is not in use at this moment. Neither command changes anything.

Check 4: Caches and logs

du -sh ~/Library/Caches ~/Library/Logs

If one is suddenly huge, an app is probably writing too much. See which caches are safe to delete.

Safe, Risky, Never

Safe

• Restarting, which clears swap and temporary files.
• Quitting a misbehaving app and clearing its cache or log.
• Emptying the Trash.

Risky

• Removing large files you do not recognize. Check what owns them first.
• Deleting snapshots you did not create.

Never

• Deleting inside /System or hidden system folders.
• Deleting a file only because it is large and new.

When it does not drop

If you clear the cause and the figure stays high, restart and give macOS a little time to recount. Part of what the Storage bar shows is space macOS can free when it needs it. The purgeable space guide explains that.

Common stories behind a jump

These are patterns, not promises. Your Mac may match none of them.

• A macOS update ran overnight. The installer and any pre-update snapshot can take many gigabytes for a few days. This one usually resolves itself.
• A sync client started a full download. Cloud folders can pull a lot of data at once, and the files may land outside System Data but still fill the disk.
• An app got stuck in a loop. A crash that repeats can write the same large log or crash report again and again. The Logs check above shows it.
• A virtual machine or container grew. Disk images for virtual machines and containers can expand quickly and shrink slowly.
• Memory pressure. A heavy overnight job can push swap use up, as the swap check shows.

What not to do in a hurry

When a number jumps, the urge is to delete something large right away. Resist it for ten minutes. A file that appeared overnight may belong to a running process. Removing it while the app is using it can corrupt a database or cause a crash on next launch.

A better order: note what the large file is, quit the app that owns it, then decide. If you cannot tell what owns a file, leave it and search its name first.

Track it so you can tell next time

Write down two numbers now: the Used figure from df -h /System/Volumes/Data and the date. Check again in a few days. If the figure falls back by itself, the cause was temporary. If it rises steadily, you have a leak, and the large-files check will show where.

Find it faster

DiskJoy is our product. Its scan is read-only today: it removes nothing, reports allocated bytes and gives a lower-bound reclaimable estimate. For a quick look at what grew, run the scan.