[SOLVED] Is there any purge facility to free up disk space?

[FrankyD]

Appears our system is starting to run low on disk space (VM running on Windows Hyper-V) and am looking for ways to reclaim disk space, as my understanding is that the emails are only temporarily stored and then removed.

Is there any tool via the GUI or commandline (Linux experience/exposure is minimal, so will need clear instructions) that can be used to locate and remove unneeded files or even purge unneeded database rows?

Alternatively, are there simple steps to follow with getting the VM image to use a larger drive, once we have allocated more space in the host?

 

[hata_ph]

Do you know what is taking up the disk space?

https://itsfoss.com/check-free-disk-space-linux/

 

[FrankyD]

Do you know what is taking up the disk space?

https://itsfoss.com/check-free-disk-space-linux/

df shows this is the largest consumption at 94%:
/dev/mapper/pmg-root

 

[hata_ph]

/dev/mapper/pmg-root is your root directory.
Run below command to check which folder is taking up the space. Then you can investigate and analyze the disk usage.

sudo du -h --max-depth=1 /

 

[FrankyD]

/dev/mapper/pmg-root is your root directory.
Run below command to check which folder is taking up the space. Then you can investigate and analyze the disk usage.

sudo du -h --max-depth=1 /

This is the output, which indicates /usr and /var being the largest usage:

2.7G    /usr
16K     /dev
4.4M    /etc
2.1G    /var
304M    /boot
0       /sys
8.0K    /mnt
16K     /lost+found
4.0K    /srv
616K    /run
108K    /root
4.0K    /opt
40K     /tmp
du: cannot access '/proc/227572/task/227572/fd/3': No such file or directory
du: cannot access '/proc/227572/task/227572/fdinfo/3': No such file or directory
du: cannot access '/proc/227572/fd/4': No such file or directory
du: cannot access '/proc/227572/fdinfo/4': No such file or directory
0       /proc
4.0K    /home
4.0K    /media
5.0G    /

 

[FrankyD]

Drilling down the folder tree a large chunk of the space is used here, but I don't know if we need all of these versions and if not, what's the safe way to remove older ones:

383M    /usr/lib/modules/5.13.19-2-pve
367M    /usr/lib/modules/5.11.22-7-pve
310M    /usr/lib/modules/5.13.19-6-pve
366M    /usr/lib/modules/5.11.22-1-pve
1.4G    /usr/lib/modules

 

[hata_ph]

Check out the article about remove old kernel from PMG 10.
Btw, your PMG only have 5GB disk space?

https://landofnightandday.blogspot.com/2021/03/proxmox-mail-gateway-debian-10-remove.html

 

[FrankyD]

Check out the article about remove old kernel from PMG 10.
Btw, your PMG only have 5GB disk space?

https://landofnightandday.blogspot.com/2021/03/proxmox-mail-gateway-debian-10-remove.html

Thanks @hata_ph
Just so I don't "blow up" are system, from the below list I can remove all the packages except pve-kernel-5.13.19-6-pve, or do I need to keep all the 5.13.x packages (not familiar enough with linux to know if these are accumulative or not)?
pve-kernel-5.11
pve-kernel-5.11.22-1-pve
pve-kernel-5.11.22-7-pve
pve-kernel-5.13
pve-kernel-5.13.19-2-pve
pve-kernel-5.13.19-6-pve

Yes we originally based on 5GB as we don't get much mail and worked on the premise that it was transient storage. This is why the second part of the question above was about steps to increase the disk size.

Thanks again.

 

[hata_ph]

Technically you only need to keep the current running kernel version.

uname -r

Your PMG running on which VM platform?

 

[keeka]

As pointed out, you can use `du -sh /dir/*` to investigate directory sizes. Aside from particular use case application data, the primary consumers of storage on a modern linux system are:

• systemd journal (/var/log/journal) check out journalctl --vacuum- options
• old kernels (/boot and /usr/lib/modules) check out `apt auto autoremove --purge` and explicit removal of old kernel previous minor version.
• rotated log files (/var/log/*.gz). you can generally manually remove old rotated log files without impacting application, syslog or logrotate.
• apt cache (/var/cache/apt) see `apt autoclean` and `apt clean`.

Since PMG doesn't archive email, the only major storage requirement I think there may be is the clamav or other virus definitions.

But with 5GB storage, you're inviting trouble or more regular maintenance.

 

[FrankyD]

As pointed out, you can use `du -sh /dir/*` to investigate directory sizes. Aside from particular use case application data, the primary consumers of storage on a modern linux system are:

• systemd journal (/var/log/journal) check out journalctl --vacuum- options
• old kernels (/boot and /usr/lib/modules) check out `apt auto autoremove --purge` and explicit removal of old kernel previous minor version.
• rotated log files (/var/log/*.gz). you can generally manually remove old rotated log files without impacting application, syslog or logrotate.
• apt cache (/var/cache/apt) see `apt autoclean` and `apt clean`.

Since PMG doesn't archive email, the only major storage requirement I think there may be is the clamav or other virus definitions.

But with 5GB storage, you're inviting trouble or more regular maintenance.

Thanks @keeka
yes I get the 5GB should be greater, which is why originally sought how to grow the disk size as an alternative

 

[keeka]

yes I get the 5GB should be greater, which is why originally sought how to grow the disk size as an alternative

It looks like your guest is using LVM and I'm guessing there's no space left in the VG (pmg) to grow the LV (/dev/mapper/pmg-root).
Once you've provided some additonal storage to your guest VM (however you do that with Hyper-V), you could extend the VG, extend the LV, and finally resize the filesystem. I don't recasll the exact syntax for these 3 steps as do it so rarely and I generally avoid using LVM inside guests.

It may be easier to recreate the guest from scratch. Backup the config. Destroy the VM. Recreate it, with more storage this time!, and restore the PMG backup. Use PMG's config backup utility for both backup and restore.
Backup the existing VM first, of course. AIUI the only data you may lose, by doing this, is the bayes spam characteristics. Could be wrong though. I am not sure how to reinstate that, if it is important to you.

EDIT: also check no mail in the queues prior to taking down the existing guest.

 

[FrankyD]

Thank you @hata_ph and @keeka
For anyone that comes across this post, removing the old kernels using the link from this post: https://forum.proxmox.com/threads/i...lity-to-free-up-disk-space.110575/post-476291
and purging the journal as per this post: https://forum.proxmox.com/threads/i...lity-to-free-up-disk-space.110575/post-476312
means we have about 40% free disk space.

All that is needed now is to learn/workout how to expand/extend volume groups (VG) and logical volume management (LVM) partitions

 

[hata_ph]

Check out below guide on LVM extend. Test it on a dummy vm first and remember backup your PMG before hand.

https://computingforgeeks.com/extending-root-filesystem-using-lvm-linux/

 

[keeka]

I wasn't sure why you had opted for LVM when setting up PMG. Then I looked at the install docs and it seems a bare metal or VM install will bring you LVM or ZFS. I had installed PMG, in Promox PVE, using their container template. Therefore did't have LVM in the guest.
I can't see the benefit in using LVM in a guest. Particularly with something like PMG which, as you said, doesn't have significant ongoing storage demands. That being said, you have numerous options to extend the root fs with LVM. ANother option is mounting /var on another volume.