You’ve probably solved this problem by now, but I had a similar issue and solved it.
I created a droplet that was 20gb, then took a snapshot and created a new 30gb droplet from that snapshot. Running df -h on the new droplet still showed 20gb.
Tech support linked me to this unanswered question (accidentally) and an article that contained information that mainly applied to resizing additional filesystems (ie, those without the OS), but the main command did the trick for me. Simply run the following command:
sudo resize2fs /dev/disk/by-label/DOROOT
Resize2fs is safe to use on live filesystems with an OS. Here is a note from the resize2fs manual page:
“If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel and the file system supports on-line resizing. (Modern Linux 2.6 kernels will support on-line resize for filesystems mounted using ext3 and ext4)”
Still, if you’re paranoid about data loss like me, and if you’ve made any changes since spinning up the new droplet, create a snapshot backup for yourself before running resize2fs.
In your specific case, I think the problem was that you were using the disk name instead of the volume name. The volume name and path is what appears when you run df -H, which for me was:
Filesystem Size Used Avail Use% Mounted on
..
/dev/disk/by-label/DOROOT 22G 12G 10G 55% /
..
Whereas /dev/vda was my disk name, as it appeared in parted.
Do you have a ticket number for your support request on this? I can look into it for you.
Well I resize de droplet again so the issue got restored at the end, I appreciate your interest to help me