I've successfully copied a large database backup file (35 GB) into the Docker container and restored my database locally (following this walkthrough). I want to now delete that .bak file from the Docker container to reclaim the space. I did that by running sudo docker exec sql_server rm -rf /var/opt/mssql/backup/example.bak
but this didn’t reclaim the space - my Docker.raw file remains about 76 GB. When I run docker system df
it says my containers are 45 GB though. I tried docker system prune -a
but this reclaimed 0B. Restarting Docker didn't do the trick. How do I shrink that now that the file is removed in order to gain that space back?
A stopped container's writable layers still take up disk space. To clean this up, you can use the docker container prune command. By default, you are prompted to continue. To bypass the prompt, use the -f or --force flag.
Volumes are never deleted unless the parent container is deleted with docker rm -v container_id and there are no other containers using the volume.
Volumes are only automatically deleted if the parent container is removed with the docker rm -v command (the -v is essential) or the --rm flag was provided to docker run. Even then, a volume will only be deleted if no other container links to it.
RECLAIMABLE is the space consumed by "unused" images (in the meaning of no containers based on thoses images is running).
I did that by running
sudo docker exec sql_server rm -rf /var/opt/mssql/backup/example.bak
but this didn’t reclaim the space
Whether this will free up space depends on whether the file exists only in the container or if it exists in your image. Once a file exists in the image, deleting it in the container doesn't modify the image itself. Instead only the container filesystem is updated with an indication that the file is deleted from the view of that container. This is how the layered filesystem works under the covers.
When I run
docker system df
it says my containers are 45 GB though
You can examine this a bit deeper. For any specific container, you can run a docker container diff
command on the container id to see the files that have been modified inside that container.
I tried
docker system prune -a
but this reclaimed 0B.
This will not reclaim space from a running container. If the container is stopped, it will be deleted, and the image that started that container may also be deleted if nothing else points to it. Otherwise docker will avoid running containers and there's no pruning it can run on the files inside a running container.
my Docker.raw file remains about 76 GB
This is a very key point, it suggests that you are running Docker on a Mac. All of the above steps may reduce disk space of the Linux environment that Docker runs on top of. However, the VM that Docker uses on Mac and Windows is mapped to a file that grows on demand as the VM needs it. From the Docker for Mac FAQ, diskspace reported by this file may not be accurate because of sparse files work on Mac:
Docker.raw consumes an insane amount of disk space!
This is an illusion. Docker uses the raw format on Macs running the Apple Filesystem (APFS). APFS supports sparse files, which compress long runs of zeroes representing unused space. The output of ls is misleading, because it lists the logical size of the file rather than its physical size. To see the physical size, add the -ks switch; to see the logical size in human readable form, add -lh:
$ cd ~/Library/Containers/com.docker.docker/Data/vms/0 $ ls -klsh Docker.raw 2333548 -rw-r--r--@ 1 akim staff 64G Dec 13 17:42 Docker.raw
In this listing, the logical size is 64GB, but the physical size is only 2.3GB.
Alternatively, you may use du (disk usage):
$ du -h Docker.raw 2,2G Docker.raw
I'd also recommend looking at how much disk space is used inside the Docker VM with:
sudo docker run --rm -v /var/lib/docker:/host/var/lib/docker:ro \
busybox df -h /host/var/lib/docker
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With