Introduction

When DirectAdmin shows the wrong disk usage after an account restore, the panel counter is often out of sync with the actual filesystem. The restore may have completed, but quota data, user tally data, or ownership metadata did not rebuild cleanly afterward.

This is not a generic mail queue problem. It is usually a quota and usage accounting problem inside the hosting stack. Start by proving what the user is really consuming on disk, then rebuild the DirectAdmin view of that data.

Symptoms

  • The restored account shows the old disk usage total instead of the new one
  • The user is reported as over quota immediately after restore
  • Deleting files does not reduce the reported usage in DirectAdmin
  • The home directory looks small from shell, but the panel reports much higher usage
  • New uploads or mailbox writes fail because DirectAdmin thinks the account is full
  • Only the restored account is wrong while other users show normal disk usage

Common Causes

  • DirectAdmin did not rebuild the restored user’s usage tally after restore
  • Filesystem quotas are disabled, stale, or not mounted correctly
  • Restored files landed with the wrong ownership, so DirectAdmin is counting inconsistently
  • Hidden data inside mail, backups, trash, or temporary directories is consuming space
  • The panel view is stale even though the real filesystem usage already changed
  • The restore brought back old archive files that were not expected

Step-by-Step Fix

  1. Measure the real usage on disk before trusting the panel by checking the restored account from shell, because if the actual usage is low while DirectAdmin shows a high number, the problem is stale accounting rather than a real storage shortage.
  2. Verify quota support is active on the filesystem that holds user data, because DirectAdmin cannot report usage reliably after restore if the partition is not mounted with working user quotas.
  3. Rebuild the affected user’s DirectAdmin usage tally from the admin side or queue the equivalent tally task for that username, because this is the first corrective action that usually fixes a stale post-restore number.
  4. Rewrite or refresh quotas if the tally alone does not fix the panel reading, because restores can leave quota metadata behind even when the restored files themselves are present and correct.
  5. Watch the DirectAdmin task queue and related error output until the recount actually finishes, because a failed tally job leaves the old usage number in place and looks like nothing changed.
  6. Inspect hidden high-usage locations inside the restored account such as mail folders, backup archives, trash folders, caches, and temporary extraction paths, because operators often discover the usage number was actually correct once those paths are checked closely.
  7. Correct ownership and permissions on restored files and directories, because mismatched ownership can make DirectAdmin and the quota system count the account inconsistently after restore.
  8. Compare the updated DirectAdmin reading with the operating system view again after the tally and quota rebuild, because matching numbers confirm the accounting issue is fixed while a remaining mismatch points to a deeper quota or panel problem.
  9. Collect the username, real filesystem usage, quota status, DirectAdmin task output, filesystem type, and any quota-related log errors if the mismatch survives a clean recount, because that evidence is what your host or DirectAdmin support needs to diagnose a restore or quota subsystem fault.