Bug? Cloudmin ssh backup unable to make directories on the target since addition of S3 backups

Hi Folks, Might be a bug or this may be a coincidence, however, since the S3 backup upgrade (version 7 I believe) My SSH backup jobs are failing. all 9 VM backups failed with the equivalent message, but I have only included one - the error is as follows :

/c/backup/virtual/2013-04-26/postgres-old.gz on SSH server 216.xxx.xxx.33 as root
2013-04-26 00:00 postgres-old Failed :
Failed to upload test file to destination system 216.xxx.xxx.33 :
scp: /c/backup/virtual/2013-04-26/postgres-old.gz.cloudmin-test: No such file or directory

The VM backups are set to go off at midnight and they failed, however I have a postgres backup using the postgres webmin module and it fires at 2am, and it had no trouble making the directory. Today I manually fired a VM backup of one host (with the directories already present thanks to postgres backup) and the backup went without a hitch (I snipped it off after one completed backup):

Backing up 4 systems to /c/backup/virtual/%Y-%m-%d
on SSH server 216.xxx.xxx.33 as root ..

Finding systems to backup ..
.. found 4 systems
Working out backup destinations ..
.. found 4 usable destinations

Backing up geoserver2 to /c/backup/virtual/2013-04-26/geoserver2.gz
on SSH server 216.xxx.xxx.33 as root ..
Creating LVM snapshots for disks of geoserver2 ..
Compressing LVM disks for geoserver2 via SSH to 216.xxx.xxx.33
..................................................................................
EXTRA DOTS REMOVED FOR BREVITY
................................................................
Removing LVM snapshots for disks of geoserver2 ..
.. created backup of 2.99 GB
Saving details of system geoserver2 to
/c/backup/virtual/2013-04-26/geoserver2.serv
on SSH server 216.xxx.xxx.33 as root ..
.. done

Saving list of disks for geoserver2 to
/c/backup/virtual/2013-04-26/geoserver2.disks on
SSH server 216.xxx.xxx.33 as root ..
.. done

Backing up postgres-old to
/c/backup/virtual/2013-04-26/postgres-old.gz on
SSH server 216.xxx.xxx.33 as root ..
Creating LVM snapshots for disks of postgres-old ..
Compressing LVM disks for postgres-old via SSH to 216.xxx.xxx.33
..................................................................................
SNIPPED OFF HERE

As a temp workaround until you can sort out if this is a bug or not and if you can fix it, I must change the order of my backups and make the postgres backup fire at midnight and the VM backups at 2 am. however this is not ideal, but it will tide me over.

Thanks Folks! Franco

Status: 
Closed (fixed)

Comments

This is indeed a bug .. if the destination directory doesn't already exist, Cloudmin's attempt to upload a test file to that directory will fail. The work-around till the next release is to create the destination directory in advance.

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