Transfer Virtual Server runs but fails, reporting lack of space when there is space!

Submitted by sebholmes on Mon, 10/16/2017 - 04:05

I have a customer whose email I want to transfer from an old Virtualmin server to a new Virtualmin Pro server. That’s easy I thought, I’ll just use ‘Transfer Virtual Server’ which I have done quickly, easily, successfully and painlessly in the past. So I initiated the process and after a wait I got the following:

Transferring xyz.com to server.hosting.com ..
Backing up to destination system ..
Creating TAR file of home directory ..
.. TAR failed! cat: write error: No space left on device
.. backup to remote system failed!
.. transfer failed
Return to virtual server details

So, I checked and found:

  1. The source Virtual Server is reported as occupying 6.14GB and is allocated 7GB total space.
  2. The destination Virtualmin Pro Server System Information screen says that the server is using 14.15GB of a total disk space of 117.01GB.

So, since the destination seems to have so much free space, I assumed that the error message was itself erroneous and so I increased the allocated space on the source server to 14GB in case the TAR file was being created on the source before being transferred to the destination, but sadly I got an identical result.

So the question is, why is the process reporting a lack of space when there appears to be 102GB+ of space? And, more to the point, what do I need to do to get round the problem?

Many thanks in advance.

Status: 
Active

Comments

Submitted by sebholmes on Mon, 10/16/2017 - 04:46

On reflection, I thought I would check the Default Plan size on the destination just in case. It was set to 12GB, so I increased it to 15GB and tried again. No change - same result.

Submitted by andreychek on Mon, 10/16/2017 - 10:27

Howdy -- thanks for contacting us!

It looks like it's running out of space while trying to make a backup of it on the original system.

What is the output of this command on both the old and new servers:

df -h

Submitted by sebholmes on Mon, 10/16/2017 - 11:09

Thanks Eric.

On the old source server, I get: root@mail:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/mail0-root 18G 8.4G 8.1G 51% / udev 1.9G 4.0K 1.9G 1% /dev tmpfs 377M 320K 377M 1% /run none 5.0M 4.0K 5.0M 1% /run/lock none 1.9G 0 1.9G 0% /run/shm /dev/sda1 228M 34M 183M 16% /boot /dev/mapper/home-home 123G 86G 31G 74% /home

On the destination:

[root@mail ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 118G 16G 97G 14% / devtmpfs 2.0G 0 2.0G 0% /dev tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 2.0G 161M 1.8G 9% /run tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup tmpfs 396M 0 396M 0% /run/user/0

Hope that helps! Incidentally, I feel that there may be something missing in Virtualmin to do with disk space generally. On more than one occasion I have been tried to apply patches only to be told that there is insufficient disk space and yet if I go to the System Information page there is plenty available. It seems to me that the System Information page should show all aspects of disk space so that an administrator should be able to see at a glance if there is a problem looming. If the info that I have provided via the 'df -h' command above confirms a problem with disk space, then that is yet more argument to add the missing functionality!

Constructively and gratefully...

Submitted by andreychek on Mon, 10/16/2017 - 13:08

Hmm, it definitely appears that you should have plenty of space for applying updates on the source server, though I could potentially see a case for there not being enough to generate a backup.

Backups are created in /tmp, which is on the "/" partition... it looks like there is about 8GB available there. That might be small enough that it's causing an issue.

Do you by chance have the ability to free up a little space there?

If not, the other option is that we can go over some steps for changing what Virtualmin uses for your temp directory.