I have a Nextcloud App running inside Docker and a problem with the storage. I have a Virtual Private Server with a 40GB SSD and an Ubuntu OS. Additionally I’ve mounted a 120GB disk. The problem is that now the 40GB SSD is completely full and the Nextcloud App is no longer accessible. Is there a solution to the problem? I would like to have that the Nextcloud App uses the 120GB disk instead of or additionally to the 40GB SSD. Is that possible and how to do that? Every help is appreciated
Docker version 20.10.17
Please let me know if I can provide further information and thank you for your help.
Given hat you’re asking on the Docker forum: I’m quite sure that telling us how you start Nextcloud (Dockerfile, Compose file, what else?) and maybe how you mounted the larger disk, will help people diving into this.
Hi, that’s the compose file I used:
# to start the service use:
# sudo docker network create proxy-tier
# sudo docker-compose up -d
# source: https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/with-nginx-proxy/mariadb/apache
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
First of all everything worked out fine. Some month later I mounted the disk to try a backup attempt. I did not work, however the disk remained mounted. I think I created a mount point and an entry in /etc/fstab and then mounted the disk using the mount command.
Thanks for your reply.
Your volumes are most likey stored underneath the docker data root folder, which typical is /var/lib/docker.
It is possible to use named volumes that use bind to point its data directory to an arbitrary directory on the host:
device: need to definie the path where the data should be stored - which should be with the mountpoint where you mounted the 2nd blockdevice into. Make sure the path exist!
Now here it the thing: the configuration of a volume is immutable, as such if the configuration is changed in the compose file, it will still not be applied to the volume unless the volume is manualy deleted and re-created by docker-compose.
But since you probably already have data in the named volumes, you need to create a backup of them, then delete the volumes, create the new vooumes and restore the backup. Forum search should yield results about this topic, if you don’t already have a backup/restore strategie.
You could also just declare new volumes names for your bind baked volumes and then use a temporary one-shot container that mounts the old and new volume, to copy the data from the old volume to the new volume (make sure no containers that use either one of both volumes are running). This approach might be easier, but will result in a changed volume name.