Backup and restore

Hello

I’d like to knwo if it is possible to backup a siteworx account and restore it as an other account.

In fact I have few clients whom develop some websites. They wwould like to develop them under their own account, then create a new siteworx account (so a new domain) with the data of their own siteworx account.

My idea was to backup their accounts then restore them under a new domaine name.

for example,
the backup of toto.com is restored under titi.com

Maybe the futur reseller management will allow to do this.
One person has few domains under his one siteworx account, then we create from his account a new siteworx account with one of his domain. The idea behind this is to easily allow a person to sell a full package :
Website development +
domaine +
Hosting

Thanks
Pascal

I’ve talked to Socheat a lot about the backup/restore system and as I understand it this would not work. The system in it’s current form depends on the system user name (first 8 letters of the domain name). They needed to do that to solve some issies.

You could probably do some things manually and make these changes but your databases (for example) would still have the original user’s name attatched to the front.

Tim’s right, it would be impossible to do completely through the restore script. However, the restore script can do some of the work for you, but you’ll need to do the rest manually.

[B]First, a disclaimer to anyone attempting this. You will be modifying the backup format, and it will obviously break quite a few things, to what degree depends on how much you try to change. If you do decide to do this on any account (production, live, test, etc), we can’t offer any support because you will cause things to happen that wouldn’t normally happen under regular use of InterWorx. It could even cause problems with other accounts on the InterWorx box. As this is an untested/unsupported scenario, I feel it better to say what could happen, or go wrong, rather than to not mention it at all.

So, basically, if you modify your backup file and restore it, you’ve voided your support rights for that account and you’re on your own. :wink: [/B]

Here’s what you can do. Untar the backup file to a temp location. You’ll see two files: <uniqname>.ini and <backup_filename>.data.tar.gz. Edit the ini file and look for the header: “[siteworx.account_info]”. Beneath that, you should see a line that says: domain=<domain>. Change <domain> to whatever your new domain is. You could also try Save and exit the file. Then, retar the contents. The command will look something like this:

tar -cvzf <backup_filename>.tar.gz <uniqname>.ini <backup_filename>.data.tar.gz

Note that the first filename does NOT have “data” in the filename, and the second DOES have “data” in it.

If you did everything correctly, you can try restoring this backup file. This should restore a few things, such as quotas, and package options (max # of domains, email boxes, etc). It should also recreate the email addresses but with the new domain name, as well as the FTP accounts.

Now, here are all the warnings. :slight_smile: Note, this is not a comprehensive list. I’m sure there are plenty of other things that will break. :stuck_out_tongue:

1.) The siteworx accountn is extremely dependent on the uniqname and domain name. The uniqname is used to name the databases, and thus the database dumps will have “<uniqname>_<dbname>” embedded in the dumps. This means database data won’t be restored.

2.) A lot of backup data is simply the ~uniqname/var directory tarred from the original account’s directory. We organize account data in directories named after the domain. For example, toto.com:
uniqname = totocom
homedir = /home/totocom/
siteworx data dir = <homedir>/var/toto.com/

If you were to change the domain name to titi.com, some paths will be wrong, and things will get “lost” in the restore process. “Lost” in the sense they will not be restored.

3.) path information in the actual web data files could be incorrect. You will need to edit all your HTML, PHP, etc, etc files to accomodate.

4.) many more things. :slight_smile:

Just thought of another option. You could untar the backup, and make all these necessary changes to the files yourself, and retar them. That is, fix all the paths to match the new domain and uniqname, edit the ini file to match, and edit all the database dumps to contain the new uniqname. This will require also untarring the inner data.tar, and retarring that before retarring the main archive. This is even more work on your part, with the same caveats and warnings, with no guarantee of working.

If you do give it a try, I’d be interested in hearing what breaks and what works. It’s a lot of work. Unfortunately, we can’t offer much more help on the matter than this. I hope I’ve convinced you, and anyone else who is thinking about modifying their backup file, that this is a very bad thing to do. :slight_smile: