BACKUPS Failing to write .serv files

Hi Guys,

Hope you are doing well, I came across an issue in Cloudmin 6.2 that I think is pretty serious. I have my XEN instances backed up nightly as a precaution after having my data store corrupt about 10 days ago and have noticed the following in the logs recently:

Backing up to /backups/xen-images/nightly/ on FTP server as manager ..
    Compressing LVM disks for ..
    Sending backup for to /backups/xen-images/nightly/ on FTP server as manager ..
. created backup of 537.48 MB

Saving details of system to /backups/xen-images/nightly/ on FTP server as manager ..
. saving failed : command-line line 0: Missing argument.
lost connection

Also, I was attempting to restore backups of images using the Backup Log yesterday morning after upgrading to Cloudmin 6.2 and kept getting a Connection Timed out message instantly as shown in the attachment. I tested FTP logins from the host Cloudmin master node to the backup and had no issues connecting. I did however get the following message which I can't say for sure is new or not :

[root@gx3 ~]# ftp
ftp> open
Connected to
220 Welcome to blah FTP service.
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (

I ended up having to manually transfer a backup file at 3am yesterday via ssh to the host I was trying to restore to and unzip it manually. No .cfg file was inside the gz or on the backup host so I was glad I had a copy. I am imagining that the .serv file contains the .cfg file for xen and allows restoring on hosts that do not have the original .cfg file.

The restore from backup log has worked in the past (nothing has changed on my end). I know that it worked great on 6.1.

Anyways, I it is a known issue and an easy fix since it is pretty darn important : ).

Take it easy guys,


Closed (fixed)


Looks like this is a bug that only effects FTP backups, and only impacts the .serv file that contains meta-information about the VM which is used if it is deleted and needs to be re-created.

I am working on a fix for this now. The work-around is to backup and restore using SSH if you can, rather than FTP. Is that possible?

Hi Jamie,

Thx for looking into this, I will change to SSH for now.


I have implemented a fix for this, which will be in the next Cloudmin release.

Getting new errors with SSH Backups (See attached)

I have a theory, I know that with Cloudmin 6.2 swap img files are not backed up by default. I know that With the 2 servers that are having an issue, I had manually setup their swap drives to not backup (prior to 6.2). For whatever reason the Cloudmin Backup is trying to tar those swap drives in the backup and I can't tell it not to with Cloudmin 6.2.


That looks like a separate issue .. does that .gz.2 file mentioned in the error exist on the destination system, and if so how large is it?

Hi Jamie,

No, it does not get created on the destination server.

Ok, I see the cause now - that's another bug :-(

Fortunately it isn't too harmful, as you are only missing the backup for a disk that would have been skipped anyway.

Please see the VPS-BACKUP-FILES.PNG for the files that are being created on the Destination host.

Both of the systems failing have 3 drives (see attached)

The 3rd Partition of 2GB is the Swap (Virtual Memory - See attached)

My Theory is that since I had manually set these VPS systems not to backup the Swap drives, that somehow when that became the defacto method in 6.2 it is causing a reverse affect (Why not bring back that yes/no option? And set to No by default).


Awesome, glad you found it.

When is the next release scheduled? Can you share the fix with me to implement?

Please mark this as fixed again.


That confirms my suspicions - the "missing" file is the one ending in .2 , which is for the 3rd (swap) disk.

I can send you a fix for these issues if you like?

Ok, I have sent you an update .deb file.

Hi Jamie,

The final fix worked like a charm, please mark this as fixed.


Automatically closed -- issue fixed for 2 weeks with no activity.