Restoring a backup fails if home directory contains symbolic links

Submitted by datenimperator on Sun, 08/08/2010 - 08:14

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

Submitted by JamieCameron on Sun, 08/08/2010 - 19:20

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?

Submitted by datenimperator on Mon, 08/09/2010 - 00:06

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

Submitted by JamieCameron on Mon, 08/09/2010 - 17:20

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

Submitted by datenimperator on Mon, 08/09/2010 - 23:44

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

Submitted by JamieCameron on Tue, 08/10/2010 - 00:45

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..

Submitted by datenimperator on Tue, 08/10/2010 - 04:38

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?

Submitted by JamieCameron on Tue, 08/10/2010 - 17:25

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?

Submitted by mmenozzi on Wed, 04/27/2016 - 12:33

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

Submitted by JamieCameron on Wed, 04/27/2016 - 23:03

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.