Reproducable Backup via SSH Problem

I've been able to reproduce the following problem multiple times and on clean (OS) installs. It appears that the Scheduled Backup via SSH feature does not create new directories beyond 2 child folders.

In attachment "backup-schedule1.gif" you'll see that all backup schedules are the same with the exception of the directory locations and that one is disabled. All 3 active backups fail, whether being done automatically by cron or if manually initiated (see image not-work-files.gif). However in image "backup-schedule2.gif" all backups are enabled. The backup job that was disabled in backup-schedule1.gif but now enabled in backup-schedule2.gif works. The backups/%d-%m-%Y folder is created no problem (working-files.gif).

I've gone through this multiple times on multiple clean CentOS installs (and clean Virtualmin installs) and it seems to only allow the creation of 2 levels of directories and no more.

So these would work...
/home/username/%d-%m-%Y
/home/username/random/%d-%m-%Y
/home/username/another/a-backup-file-%d

However these would not...
/home/username/backups/random/%d-%m-%Y
/home/username/random/level2/level3%d-%m-%Y
/home/username/backups/level2/level3/leve4/a-backup-file-%d

Problem only occurs with backup via SSH, local backups do not experience the same issue.

I was running something very similar, if not exact, to this setup just last week without issue. Perhaps there's been a recent change to the Backup functions that's impacted this?

I hope I'm explaining this well enough.

Status: 
Closed (fixed)

Comments

There was a bug like this recently in the 3.86 release of Virtualmin .. but it should be fixed in 3.87.

Have you upgraded to 3.87 yet?

I've been using clean Virtualmin installs for the past few days using: wget http://software.virtualmin.com/gpl/scripts/install.sh

Is this not the way to get the latest stable releases? My Virtualmin installs only show 3.84.gpl GPL. The most recent taken from the above URL was about 20 minutes ago and still shows as 3.84.

You don't need to re-run that install script to upgrade .. instead, it should setup a YUM repository so that you can upgrade with the command yum install wbm-virtual-server

Just to be clear, I'm only running that script once per OS install. We're a dedicated server provider and my testing has required me to install CentOS fresh, then the virtualmin script every time.

So the 3.84 version I have is from a clean CentOS5.6 install completed about 30 minutes ago. Then the install.sh script was downloaded and run as mentioned above. Given this is a brand-new install and virtualmin install I will still need to do an update using yum?

Jamie, something may be wrong with the repodata for the Virtualmin GPL repository.

Although there is indeed a Virtualmin 3.87 released in there, the repository metadata was last updated in early March, when Virtualmin 3.84 was released.

This may be something Joe needs to correct, though I'm going to see if I can verify that before we bug him.

In the meantime cass, you can always manually grab the Virtualmin 3.87 RPM from here and install it:

http://software.virtualmin.com/gpl/universal/wbm-virtual-server-3.87.gpl...

That is very unusual, as I just did a clean install onto a CentOS 5.6 EC2 instance and it picked up Virtualmin 3.87.

If you run yum clean all ; yum info wbm-virtual-server , what does it output?

Also, what does your /etc/yum.repos.d/virtualmin.repo file contain?

Okay, there's definitely a problem with the software repositories, I'm reassigning this to Joe.

Thanks for the link, andreychek. Glad to hear the bug was fixed, sorry to hear about the repo problem. :) And thanks for your help too Jamie.

By the way, I came to the same conclusion as andreychek a few minutes ago based on the following.

[root@mtest ~]# yum install wbm-virtual-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.mirror.nexicom.net
* extras: centos.mirror.nexicom.net
* updates: centos.mirror.nexicom.net
base | 1.1 kB 00:00
extras | 2.1 kB 00:00
updates | 1.9 kB 00:00
virtualmin | 951 B 00:00
virtualmin-universal | 951 B 00:00
Setting up Install Process
Package wbm-virtual-server-3.84.gpl-1.noarch already installed and latest version
Nothing to do
[root@mtest ~]#

Jamie, what I had done was to remove "wbm-virtual-server" on my CentOS GPL test system using:

rpm -e --nodeps wbm-virtual-server

I then ran "yum clean all", followed by reinstalling wbm-virtual-server.

When I reinstalled it, it was version 3.84 that it installed.

Sheesh you guys are quick.

Jamie, as per your request.

/etc/yum.repos.d/virtualmin.repo

[root@mtest ~]# cat /etc/yum.repos.d/virtualmin.repo
[virtualmin]
name=Red Hat Enterprise $releasever - $basearch - Virtualmin
baseurl=http://software.virtualmin.com/gpl/rhel/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

[virtualmin-universal]
name=Virtualmin Distribution Neutral
baseurl=http://software.virtualmin.com/gpl/universal/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

yum clean all ; yum info wbm-virtual-server

[root@mtest ~]# yum clean all ; yum info wbm-virtual-server
Loaded plugins: fastestmirror
Cleaning up Everything
Cleaning up list of fastest mirrors
Loaded plugins: fastestmirror
Determining fastest mirrors
* base: centos.mirror.nexicom.net
* extras: centos.mirror.nexicom.net
* updates: centos.mirror.nexicom.net
base | 1.1 kB 00:00
base/primary | 954 kB 00:00
base 2683/2683
extras | 2.1 kB 00:00
extras/primary_db | 183 kB 00:00
updates | 1.9 kB 00:00
updates/primary_db | 627 kB 00:00
virtualmin | 951 B 00:00
virtualmin/primary | 83 kB 00:00
virtualmin 304/304
virtualmin-universal | 951 B 00:00
virtualmin-universal/primary | 15 kB 00:00
virtualmin-universal 126/126
Installed Packages
Name : wbm-virtual-server
Arch : noarch
Version : 3.84.gpl
Release : 1
Size : 5.2 M
Repo : installed
Summary : Webmin module for 'Virtualmin Virtual Servers (GPL)'
License : Freeware
Description: Webmin module for 'Virtualmin Virtual Servers (GPL)' in RPM format

Sorry for the spam guys. Just wanted you to know that I checked out an older (~10 days old) install of Virtualmin on a different machine and it reports 3.87. So perhaps just some of your repos/mirrors have reverted back to 3.84 or were never updated. Both 3.87 box and 3.84 boxes installed at same data center.

Cheers, Cass

Try the yum clean all ; yum info wbm-virtual-server again now .. I re-built our repo metadata, as it may have been out of date.

Rebuilding the metadata seems to have fixed the problem, as I'm pulling down 3.87 now.

Thanks!

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