I'm a monoglot, so I'll have to stick with English sorry, but there are a few different ways you can go with this. There are pros and cons whichever way you go, but I'll lay out the options as I see them (likely not exhaustive; but hopefully the "most reasonable" choices).

Before I get started, it's well worth noting that TurnKey is based on Debian (v15.x = Debian 9/Stretch). So any Debian instructions you find online will almost certainly work with TurnKey (although we do make some default config changes - nothing that should affect addressing this particular question). Ubuntu is also based on Debian, so Ubuntu specific info, will also often apply to the context of many things. However it is worth noting that Ubuntu is not completely binary compatible with Debian (TurnKey is). So as a general rule, installing software complied for Ubuntu (e.g. Ubuntu PPAs) on TurnKey is generally not a good idea (unless it explicitly supports Debian too). Instructions for other distros, may also apply to a point, but they often use alternate package management system (as opposed to apt). They can also have alternate base config setup for particular software (e.g. Apache) and may also use different compile time flags/config.

It's also well worth noting that if you have important data on your server and/or have already spent time on setup and config, you'll want to ensure that you have a working backup of your system. Our built-in automated remote backup tool; TKLBAM may be a good option, although there are plenty of others.

To answer your question more specifically, here are the main options I can think of:

Add a new vHDD to the LVM

By default, TurnKey "VM" builds (both the VMDK and the OVA) use LVM. LVM is a disk volume abstraction layer that provides a lot of flexibility. Under LVM it's possible to add an additional vHDD in such a way as to extend the existing filesystem. I.e. multiple disks that present to the system as if they were it were one large disk.

There is actually a TurnKey blog post/tutorial that covers this process. It's quite dated, but should still work exactly as is (I actually still use it as a reference from time to time).

Increase the size of the existing virtual disk

Next up is a slightly different way to essentially achevie the same ends. However this time, rather than adding a new disk, you increase the size of the existing one. The blog post I noted above should still be useful if you go this path as you will still need to extend the VG and LV (of the LVM).

Add a new (virtual) disk for user data

The final suggestion on achieving your ends is a little more involved, but may be a superior option as using separate drives/partitions for the userdata means that your main OS won't run out of room, even if you fill up the space you allocated for Nextcloud files (although obviously, it may still fill for other reasons...).

Either way, you'll need to add a new vHDD or extend the existing one, as per the first step of either of the above options. If you wish, you could use LVM here too. If adding a new vHDD, add it as a new PV, then add it to the VG. Either way, create a new LV for your user data and format it. Once you have the new volume (whether using LVM or not) then the process looks something like this:

• Stop Apache, so that no new data is being written to the Nextcloud data
• mount the volume; I suggest something like /media/userdata-vol (or similar)
• copy the existing data/file structure from the location that you intend to replace onto the new volume
• mount bind /media/userdata-vol (or whatever you called it) over the top of the desired file structure (so the file structure looks exactly as it did before)
• Start Apache again and ensure that everything is working as it should. The only issue I'd potentially anticipate is permissions; Nextcloud runs under the www-data (system webserver) user account, so will need read/write permissions to the user data
• Assuming all works well, add both the initial mount point and the mount bind to your /etc/fstab file (so that they are reloaded on boot)
• Reboot your server to ensure that everything is working as it should be (i.e. the mount points are mounted as configured
Assuming that everything is working as it should be, you could optionally get back the lost disk space by cleaning up the old filesystem (i.e. the bit that has been "covered" by the bind mount). To do that, stop Apache again, unmount the bind mount point, delete the relevant Nextcloud user data file hierarchy (the bit that you've copied to the new disk), leaving an empty directory where the new disk is being bind mounted. Reboot again to double check all is well, and you should be all good.

Final note is that whilst the last option isn't particularly detailed, as per my note above about Debian/Ubuntu, you should be able to find tons of info and tutorials online (likely in German too) on the specifics of how to do this. Beyond the location of the Nextcloud userdata (IIRC it's a sub directory of /var/www/nextcloud/data; but I can't be sure sorry) these steps are generic Linux (not specific to Nextcloud).

If you need any additional explanation, a few more pointers or some details filled in, please post back. The more info you can share on which direction you go and how you got to where you're experiencing the issue, the easier it will be to point you in the right direction.

Good luck! :)