Tencent Cloud Business KYC Benefits How to Find Hidden Large Files When Tencent Cloud CVM Disk Is 100% Full

If your Tencent Cloud CVM disk has already hit 100%, the problem is usually not “too many files” in the abstract. In real incidents, it is often one of these: logs exploding overnight, Docker layers piling up, deleted files still held by processes, a database growing in the wrong partition, or a backup task writing to the system disk by mistake.

The fastest way to recover space is not to browse directories manually. You need to identify the real storage consumer first, then decide whether to clean, rotate, compress, move, or temporarily expand the disk. If you wait too long, services can fail, Tencent Cloud agents may stop working, and even SSH login can become unstable.

What I check first when CVM is already full

1. Confirm whether the problem is block space or inode exhaustion.
   A disk can show 100% used even when the file size total does not look huge. Sometimes the issue is inode exhaustion, especially on systems with massive small files.
2. Find the top-level mount that is full.
   On Tencent Cloud CVM, system disks and data disks are often mixed in practice because someone mounted a database or log path incorrectly.
3. Look for “deleted but still open” files.
   This is one of the most common reasons a disk stays full after you delete large files.
4. Check logs, containers, and snapshots first.
   In production, these are the most likely hidden space hogs.

Step 1: Confirm the real disk pressure

df -h
df -i

If df -h shows 100% but df -i is fine, you are dealing with block space, not inode exhaustion. If both are near full, small-file cleanup matters as much as large-file cleanup.

Tencent Cloud Business KYC Benefits Then identify which mount is causing the issue:

lsblk
mount
du -xhd1 / | sort -h

The -x flag is important. Without it, du may cross into other mounted disks and give you a misleading picture.

Step 2: Find the directory that is actually eating the space

Start from the root of the full mount and drill down only into the biggest directory each time. This is much faster than scanning the whole filesystem at once.

du -xhd1 /var | sort -h
du -xhd1 /var/log | sort -h
du -xhd1 /home | sort -h
du -xhd1 /data | sort -h

In practice, the usual suspects are:

• /var/log — system logs, application logs, audit logs
• /tmp and /var/tmp — temporary uploads, unzip leftovers, failed jobs
• /root and hidden dot-directories — accidental backups, tarballs, scripts
• /data — databases, uploaded media, caches
• Tencent Cloud Business KYC Benefits Docker paths such as /var/lib/docker

Step 3: Find hidden large files, not just visible ones

Many users check only obvious files and miss the real problem. Hidden files often live under dot directories or are named like normal config files. Use find with size filtering to locate the biggest files directly.

find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null | sort -k5 -h

If you want a faster first pass, search by common large-file patterns:

find /var/log -type f \( -name "*.log" -o -name "*.gz" -o -name "*.old" \) -exec du -h {} + | sort -h
find / -xdev -type f \( -name "*.sql" -o -name "*.tar" -o -name "*.zip" -o -name "*.dump" \) 2>/dev/null

Tencent Cloud Business KYC Benefits If you have access to ncdu, it is one of the quickest ways to visualize what is consuming space:

ncdu -x /

In live production, I usually start with du and then switch to ncdu for confirmation if the server is not too busy.

Step 4: Check for deleted files still held by running processes

This is a classic trap. You delete a 20 GB log file, but the disk usage barely changes because the process still has the file handle open. The space is not released until the process closes it.

lsof | grep deleted
lsof +L1

If you see deleted files with huge sizes, identify the process and restart it safely. Common offenders are:

• Java application servers
• Nginx or custom log daemons
• Database services
• Containers with deleted overlay files

Example: if a log file was removed but the process still holds it open, a service restart may release several gigabytes instantly. On a busy CVM, that can be the difference between normal operation and a cascading outage.

Step 5: Check Docker and container storage separately

If the CVM runs Docker, many users look in /var/log and still cannot find where the disk went. Docker can quietly consume huge space through images, stopped containers, build cache, and container logs.

docker system df
docker ps -a --size
du -sh /var/lib/docker

What usually grows fastest:

• Old images no longer used
• Build cache from CI runs
• Container logs under /var/lib/docker/containers
• Volumes attached by forgotten test environments

Cleanup should be careful. Do not blindly run broad prune commands in production without checking whether the images or volumes are still needed. The cheapest mistake is not storage; it is deleting a volume that contains data you cannot rebuild.

Step 6: Search for oversized logs and wrong log rotation settings

On Tencent Cloud CVM, many “disk full” incidents are actually log rotation failures. The app keeps writing, but no one noticed that the log file has not rotated in weeks.

du -sh /var/log/*
ls -lhS /var/log | head
cat /etc/logrotate.conf
ls /etc/logrotate.d/

Real-world issues I often see:

• Logrotate exists, but the app writes to a custom path not covered by any rule
• Logs are compressed too late, so one day of traffic generates several gigabytes
• Application-level debug logging was left on after testing
• Audit or access logs were copied into the same partition as the OS

If you find a large log file, do not just delete it and walk away. First check whether the service is configured to reopen logs properly after rotation.

Step 7: Hidden space inside databases and backups

When the instance hosts MySQL, PostgreSQL, Redis, or a self-managed application database, disk full is often caused by data growth, failed dumps, or backup retention mistakes.

Quick checks:

du -sh /var/lib/mysql
du -sh /var/lib/postgresql
du -sh /data/mysql
du -sh /backup
du -sh /data/backup

What I see most often:

• Binary logs not being purged
• Failed backup jobs leaving partial dump files
• Daily exports written to the system disk instead of the data disk
• Compressed archives accumulating because no retention policy exists

If the database itself is the growth source, deleting random files is not the solution. You need to either fix retention, move the data path, or expand the disk.

When du doesn’t match df

This mismatch is one of the most confusing things for users: du says the directories total 40 GB, but df shows 100 GB used.

The main reasons are:

• Deleted files still open by processes
• Files on mounted paths that du did not scan the way you expected
• Reserved blocks on ext filesystems
• Hidden mount points under busy directories

In this case, do these checks:

lsof +L1
mount | column -t
find / -xdev -type d -name ".snapshot" 2>/dev/null

If the server is using filesystem snapshots or backup overlays, they can also consume space invisibly from the admin’s point of view.

What to delete first, and what not to touch

When the disk is at 100%, speed matters. But the first cleanup target should be low-risk data.

If you are not sure whether a file is safe to delete, move it to a temporary location on another disk first, then verify that services remain stable. On a full system disk, this may still be enough to recover.

When cleanup is not enough: expand the disk or move the workload

There is a point where deleting files is only a temporary fix. If the instance is repeatedly filling up, you should compare the cost of cleanup time versus the cost of resizing or moving data to a separate disk.

Tencent Cloud Business KYC Benefits My practical rule: if the same CVM fills up more than once in a short period, stop treating it as an emergency cleanup issue. Treat it as capacity planning failure and redesign the storage layout.

Tencent Cloud account and payment issues that can delay the fix

This part matters more than most people expect. If you find the cause but cannot expand the disk because the account is not ready, the downtime can last much longer than the technical cleanup itself.

1) If you have not completed KYC, some actions may be blocked

On Tencent Cloud International accounts and some regional setups, identity verification can affect what you can buy, whether billing can be activated smoothly, and whether additional risk checks are triggered. If you are planning to resize disks or create new CVMs under pressure, do not wait until the outage day to verify the account.

Tencent Cloud Business KYC Benefits Common practical failure points:

• Name or company details do not match the payment method
• Document uploads are unclear or expired
• Business registration information does not match the billing profile
• The account was opened for testing but is now being used for production

2) Prepaid, credit card, and invoice-based setups behave differently

For urgent storage expansion, payment method affects speed. Credit card accounts usually recover faster when you need to renew or add capacity, but they can also trigger risk control if the billing pattern looks unusual. Prepaid balance works well if the account is managed carefully, but if funds run out during an incident, expansion may be delayed.

What I usually recommend:

• For small teams: keep a buffer balance or a valid card on file before production launch
• For larger teams: align billing owner, KYC, and procurement approval in advance
• For cross-border users: check whether the billing country, tax profile, and payment card region are consistent

3) Risk control can flag sudden spend changes

If you suddenly launch a new CVM, attach disks, or increase spend on an account that has been idle, Tencent Cloud may trigger review. This is not rare. It happens more often when:

• The account is newly registered
• The payment method was just changed
• There is a big jump in instance size or storage consumption
• Billing country, login location, and usage region look inconsistent

The practical fix is not to “avoid” review by using random details. The real fix is to keep the account profile clean, verify early, and make sure the business registration, cardholder information, and usage region make sense together.

4) Renewals can fail if you leave them to the last minute

A lot of users only discover the billing issue when the disk is already full and they are trying to renew or expand at night. If the renewal fails due to payment limits or compliance review, the impact is much worse than a normal billing reminder.

Tencent Cloud Business KYC Benefits In production environments, I strongly suggest:

• Set billing alerts before the threshold gets critical
• Tencent Cloud Business KYC Benefits Keep at least one fallback payment method if policy allows
• Tencent Cloud Business KYC Benefits Test the full renewal flow before the service reaches a risky capacity level

Real operational pattern: what usually works in under 30 minutes

In a typical incident, the fastest recovery path looks like this:

1. Run df -h and df -i to determine the type of exhaustion
2. Use du -xhd1 to find the full mount’s biggest directory
3. Check lsof +L1 for deleted files still held by processes
4. Inspect /var/log, Docker, temp directories, and backup paths
5. Delete or rotate low-risk files first
6. If cleanup is not enough, expand the disk or move the workload

In many cases, one deleted-but-open log file or one forgotten backup directory is enough to free several gigabytes quickly. That is often the difference between a short incident and a prolonged outage.

Cost comparison: clean now, expand now, or rebuild later?

If the instance runs business-critical services, I usually prefer paying for extra storage over repeatedly gambling on emergency cleanup. The labor cost of a second incident is often higher than the storage bill.

Frequently asked questions

Why does du show less usage than df?

Usually because of deleted-but-open files, hidden mount points, reserved filesystem blocks, or storage used outside the directory tree you scanned. Check lsof +L1 first.

I deleted a huge log file, but disk usage did not change. Why?

The service may still be writing to that file handle. Restart the owning process safely, then check df -h again.

Can I just clear Docker with one command?

You can, but do not do it blindly. Confirm whether unused images, containers, and volumes are really disposable. In production, the safest cleanup is targeted, not automatic.

Should I buy a bigger CVM or add a data disk?

If the system disk is full because of logs and temporary files, adding storage may only delay the problem. If your app data is naturally growing, a separate data disk is usually cleaner and easier to manage.

What if I cannot expand the disk because the Tencent Cloud account is not fully verified?

Then the operational fix is to prepare the account before the next incident: complete KYC, confirm the payment method, keep billing information consistent, and make sure renewals will not be blocked by last-minute compliance checks.

Is it cheaper to keep cleaning or to resize the disk?

If the issue happens once a year, cleaning may be enough. If it happens monthly or after each deployment, the true cost is not storage; it is repeat downtime and engineer time.

Practical takeaway

When a Tencent Cloud CVM disk is full, the right sequence is: identify the mount, find the largest directories, check deleted-but-open files, inspect logs and containers, then decide whether to clean or expand. If you are also responsible for account procurement, KYC, renewals, and billing, do not ignore those details: a verified account with a stable payment method can save hours when the disk fills at the worst possible time.

In real operations, the hidden file is rarely “hidden” in a mysterious sense. It is usually hidden by process behavior, log rotation mistakes, container storage, or a backup path nobody revisits. Find that pattern once, fix it permanently, and the next disk-full alert becomes a minor maintenance task instead of an emergency.