Restoring a backup fails if home directory contains symbolic links

Some of my domains use capistrano for deployment and symbolic links for the main web directory. Creating a backup for those works to some extend, but restoring the backup fails. Here's the directory layout:

~/releases/release1
~/releases/release2
~/releases/release3
~/current > ~/releases/release3

It'd be helpful if the virtualmin backup would leave out the symbolic links while creating the home dir tar file, and automatically recreated them upon restore. The error message reads:

/bin/tar: ./current: Cannot open: File exists
/bin/tar: Exiting with failure status due to previous errors

Kind regards,

Christian

Status: 
Active

Comments

So is your web directory set to current , which is then a link to the appropriate sub-directory?

I can see how this would cause problems, as the restore simply extracts the tar file ... and if you are restoring on a new system, Virtualmin would presumably create current as a directory for new domains?

Right. If I could exclude dirs from the backup, that'd help, but a proper solution would indeed include regeneration of the symbolic links.

So how do those links get created in the first place, if you create a new domain?

They're created by capistrano. It connects via SSH, transfers stuff (or exports from SCM) and creates links. During setup, you'll run a command like "cap deploy:cold" which will set up required directories like "releases" or "shared" and create links as appropriate. Every deployment after that will create a new release and link "current" to it if deployment was successful.

[Linke that, you can actually roll back a complete deployment if things go wrong.]

Problem is: If you replace the symbolic link "current" with a directory of that name, the next deployment will fail.

Regards,

Christian

Here's what I would suggest to handle that case - have Virtualmin turn the current directory into a link when creating a new domain, so that the restore always works. This can be done by creating a script named /etc/virtualmin-post-create containing :

#!/bin/sh
if [ "$VIRTUALSERVER_ACTION" = "CREATE_DOMAIN" ]; then
cd $VIRTUALSERVER_HOME
mv current current_dir
ln -s current_dir current
fi

Then going to System Settings -> Module Config -> Command to run after making changes to a server and entering /etc/virtualmin-post-create . Be sure to make the script executable with :

chmod +x /etc/virtualmin-post-create

This assumes that all your domains will use that same deployment style..

Unfortunately, they don't.

Eg, domains that run just plain PHP scripts like Wordpress don't use fancy SVN based versioned deployment. They could, but in fact they don't.

Additionally, I don't think that choosing one deployment style or another should interfere with the results of restoring a backup. "Backup" means "put everything in a safe place" and not "put away what you understand how to deal with"

What if the tar file contained only proper files and directories, but not links? As a pre-backup script, you could scan for symbolic links with some variation of find -type l, put the results in a file, contain it in the tar and recreate the links after all the files had been restored.

Or else?

I've looked into this some more, and on my system I was unable to replicate the issue. What I did was :

  1. Create a domain, then convert its public_html directory into a link
  2. Backup the domain
  3. Delete the domain
  4. Restore from the backup, which re-creates it and restores the home

At the end, public_html was properly re-created as a link..

Is this basically what you are doing?

@JamieCameron was the link you created a symbolic link with absolute path or relative path?

A relative path - which I'd strongly recommend, as using an absolutely path may fail if restoring onto a system in which the home base dir is different.