I moved files from my old server to a new one. I don't know why but when I want to zip my folder it always hangs on a folder.

At first, I thought it had failed, so I canceled by pressing ctrl+c, but I tried multiple times and always have same result.

My zip command is:

zip -r backup.zip /var/www -x '*.log*'

I tried so many zip commands with or without params/arg but still hangs on /admin/storage/logs/0 directory.

When hung up, the zip process was still running, so I tried to wait for about 3 hours until it was completed.

After completed, I moved .zip that has 7.7 GB size file to the new server then tried to extract it. When extracting it's returned:

/admin/storage/logs/0: write error (disk full?)

My new server has 160 GB, and the old server only has about 15 gb. What makes the new server full?

Researching I found folder /admin/storage/logs/ has a 134 GB size but when I run command ls it's empty. I deleted that folder but when I run df -h the used disk space still same.

Below is my command history:

root@ip-172-26-4-220:/var/www/www/admin/storage# du -hs * | sort -rh
134G    logs
1.2G    app
32K framework
8.0K    debugbar
root@ip-172-26-4-220:/var/www/www/admin/storage# cd logs/
root@ip-172-26-4-220:/var/www/www/admin/storage/logs# du -hs * | sort -rh
134G    0
root@ip-172-26-4-220:/var/www/www/admin/storage/logs# cd ..
root@ip-172-26-4-220:/var/www/www/admin/storage# rm -r logs/
root@ip-172-26-4-220:/var/www/www/admin/storage# du -hs * | sort -rh
1.2G    app
32K framework
8.0K    debugbar
root@ip-172-26-4-220:/var/www/www/admin/storage# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       156G  156G  2.2M 100% /
devtmpfs        3.9G     0  3.9G   0% /dev
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           796M  832K  796M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup

How to free up space?

On old server admin/storage/logs folder only has 52M:

[root@server storage]# du -hs * | sort -rh
3.4G    app
52M logs
2.7M    framework
4.0K    oauth-public.key
4.0K    oauth-private.key
4.0K    debugbar

Why was the extracted .zip file given more than 134 GB?

[root@server admin]# cd storage/logs/
[root@server logs]# ls -lh
total 51M
-rwxrwxrwx 1 root   root   1.0T Sep 30  2020 0
drwxr-xr-x 2 root   root   8.0K Sep  1 12:00 cron
-rwxrwxrwx 1 apache apache 1.6K Mar  6  2020 frontend-response-2020-03-06.log
-rwxrwxrwx 1 apache apache  720 Mar 23  2020 frontend-response-2020-03-23.log
-rwxrwxrwx 1 apache apache  353 Apr 29  2020 frontend-response-2020-04-29.log
-rwxrwxrwx 1 apache apache  719 Apr 30  2020 frontend-response-2020-04-30.log
-rw-r--r-- 1 apache apache  51M Sep  1 18:00 laravel.log
[root@server logs]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  188M  1.7G  10% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda2        36G   25G   11G  71% /
tmpfs           379M     0  379M   0% /run/user/0

wow, file 0 has 1 TB size. but why did df return only 25gb used? Maybe I need to delete it first before migrate?

  • @Tilman I updated the question, that dir has 1TB size, but df returned only 25gb total disk used Sep 1, 2021 at 14:59
  • Maybe the filesystem is broken. I had a similar problem with an image of 20 GB in NTFS, I just had to fix the filesystem. Maybe something similar happened in yours.
    – evening_g
    Sep 1, 2021 at 15:26

1 Answer 1


The file /var/www/admin/storage/logs/0 is quite probably a sparse file. That is, it doesn't contain actual data over its entire length. There are stretches that have never been written and therefore do not occupy any space on disk. If those are read then the Linux kernel just returns a series of bytes with the value 0 which compresses very well, so zip has no problem fitting the entire 1 TB file into a 7.7 GB archive. But when unpacking the archive unzip will attempt to actually write all those zeroes to disk because it doesn't know that they weren't actually there on the old server.

You have two possible courses of action:

a) Delete the file on the old server or at least exclude it from the zip archive. It probably doesn't contain anything useful anyway. A sparse logfile is quite unusual and would normally only happen because of some malfunction, improper log rotation or the like.

b) Instead of zip, use an archive program with sparse file support, like GNU tar, which is able to recreate the sparse file on the new server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .