Understanding where disk space has gone?

Chances are that the excess space are allocated to open but already deleted files.

du will only show those files which are accessible through the file system (ie: have a filename). When a file is deleted, its file name is removed from the directory, but the disk blocks (and the inode) get freed only when all processes close the open file handles to that file. The most trivial way to have problems with this is to delete open logs files, and expect the space to be freed. Then you either have to coerce the holding processes to close their file handles, or kill those processes (an exiting process always closes all its file handles). There are other ways a process could be using a file (running it as a binary, loading it as a shared object, mapping it into the memory space).

To see what open but deleted files are held by running processes, you might use utilities like lsof, or you might look into /proc/*. There, there's a directory for each process running, named with its PID (like: /proc/1 for PID number 1). Under the directory, a symlink called exe shows the binary running the as the process, a file called maps shows the files mapped into the memory space of the process, and a directory called fd lists all the open file handles of the process. If you see (deleted) there, that's it.

For interactively exploring the usage of your filesystem you can use tools like xdiskfree,kdiskfree or baobab.

You get basically the same information as in du but you don't have to us it for each subdirectory, but simply click on a directory to see details.

As previously suggested you can use du -sh command to identify total space usage of any folder.

You will want to run this command with sudo to be sure that it captures size information for everything in the folder.

The -s option causes du to recursively check disk usage.

The -h option is to make the output human readable. When you get the hang of it, you can try running du with and without -h option and compare output. Sometimes you may find the output without -h is useful.

You can also submit wildcards to the du command to assess usages of multiple folders. So:

sudo du -sh /home/* 

will give you total usages for each folder in /home

 du -sh <directory> 

gives details about the disk usage of the directory.

 du -h <directory> 

will give disk usage of each element in the directory. You can use the above to find out which are the directories that are taking disk space.

Since du / reports 51GB, 51GB is what you're using. It's possible that there's some used space that you aren't seeing, such as deleted files or files hidden by a mount point (see the end of Why are there so many different ways to measure disk usage? — in fact the whole answer is probably of interest). But in your case that's unlikely.

If the PostgresQL database was inside your filesystem, then it would appear as files and it would be counted in the total. Evidently, since it's bigger than the files you see, the database is located elsewhere, outside the directory tree that you have access to.

The 315GB may be shared with other users. Or maybe the storage space is organized so that you get to use a 315GB filesystem, but you only see part of it as your directory tree, and the database is in another part that you don't see. E.g. there's a volume /clients/richard, it has two subdirectories root and database, and you're seeing only the directory tree from /clients/richard/root (i.e. your processes are chrooted there).

The remaining 10GB may be some recovery system (many VPS have this service where you can boot into a recovery system in case you need to repair your main system that isn't booting). Or it may be an emergency reserve that only root can use (search for “reserve” in Why are there so many different ways to measure disk usage?).