Tim Collins's picture


I have tried several times to Clone a new server from latest snapshot however the new server seems completely impervious to my attemps to either SSH or Webshell into it as required below. Hence I have no way of accessing the Snapshot. The console log all looks fine, nothing unexpected.

Anyone got any bright ideas of how to get it working? 


Snapshot launch: manual action required

This server contains configurations specific to the original snapshot server, and requires reconfiguration. Please log into this server (SSH or Webshell) as root, and execute the following:

L. Arnold's picture

Go to the Snapshots view, then select Clone this Snapshot to New Cloud Server you should have a few more options.  Generally you have to rerun some scripts that a regular VM doesn't require.  Also, I recall it being important that you run on 11.3 (at least 11.2) TKL platforms  (probably pulls that up as it is).

Alternatively you should be able to do a TKLBAM restore.

I can't tell you specifics in that I don't have any active snapshots to test from.   I recall it took a few attempts to do this is all.

Ronan0's picture

Wondering why don't I have the 'clone' option? I only have an option to create an AMI. I don't get the 'clone' option when I launch an AMI either? Thanks.

Jeremy Davis's picture

If you aren't using the TKL Hub then that would probably explain why you don't have that option...

Ronan0's picture

Thanks, Jeremy. Yes, I was working from AWS.

Signed up to TKL hub now -

1. I notice since 21st April (2 days ago), you cannot retrieve secret access keys anymore (to set up server module of hub). - You have to create a New access key. Just wondering will doing this potentially upset existing turnkey deployments on the AWS account?

2. If I use "Restore this backup to a new cloud server" from the hub back-up module, might this potentially upset the existing presently deployed (production) instance the back-up is based on? For example, should I be assured it will create a brand new environment with separate back-ups, Turnkey billing subscriptions etc? Or could there be some cross-over?


Jeremy Davis's picture

Not sure what is up with secret keys/access keys... I'm assuming that you're referring to AWS API keys? Perhaps AWS have made some changes... TBH I'm not sure if it would affect your currently running instances but I wouldn't think so... The only thing that I would be concerned about is if you are referring to SSH keys, AFAIK you can only have one SSH keypair associated with your AWS account, so if you are changing them, you may wish to also change it with your other appliances (although strictly speaking I wouldn't image it would be required...)

TBH I haven't been involved with the development of the Hub and haven't used the 'clone' functionality (I use the Hub regularly but haven't ever used snapshots - perhaps it's time I did!). Knowing what I know about ALon and Liraz (the core TKL devs) though I imagine that it would 'Just work'(TM) :)

AFAIK new servers should automatically get their own unique TKLBAM backupID. Also AFAIK all your Hub instances should be billed together. So for all intents and purposes it should be a totally independent instance. However I'll do some testing so i can be confident in my comments.

[update] I just took a snapshot of a server, and then cloned a new server from it. It gets it's own IP and it's own unique backup set (when I just ran TKLBAM manually). It inherits it's root password from the snapshot. The only things that may not be intuitive (and might trip you up if you weren't careful) is that the cloned instance also inherits it's label from the original instance [from the default label for that appliance and size] (so will look the same as the original in the Hub [assuming that you haven't changed it from the default label]) - so you'll want to manually change that. Also I had a domain name attached to my original instance and the cloned one stole that domain association on launch. So that might be something to be careful of! I'm not sure whether it would act the same if you had an elasticIP attached to your instance...? (I was just using HubDNS)

[more update] I just rebooted the original instance to see what would happen and it stole it's domain name back! So that is definitely something you'll want to manually adjust! Also I have just realised that the Label is not unique, even when you launch a new server the same (i.e. not a clone) it gets the same default label. Perhaps the clone server wasn't inheriting the original server's Label, but the default label of the appliance? I will test some more!  The cloned server inherits the default label for that instance (i.e size - appliance e.g. Small Wordpress). I have edited the original post to reflect this (crossed out the incorrect bit and added the correct info in square brackets).

Ronan0's picture

Thanks for that, Jeremy. Appreciated.

Yes, I am referring to the AWS API keys. 

To initially set up the "TurnKey Cloud Servers" module in Hub, I am asked to provide my 'access key' and 'secret access key' from AWS. This request is generated by TKL Hub.

But, Amazon made a major change a few days ago, and it is no longer possible to retrieve the secret access key.

So, to get TurnKey Cloud Servers module working, I need to create new access keys. (now, you can only retrieve the secret key when you first create it.). I assume the old one will be superceeded.

I am wondering whether there is any element of my existing TKL deployments on AWS that use the old API keys, that will be affected.

Aside from the above (and I appreciate your tests on snapshot and cloning, which are very helpful to me), I was wondering about the other module of Hub - "TurnKey Backup and Migration".

- As per my post above, if within this module I "Restore this backup to a new cloud server", does that acheive the cloning with the kind of integrity you discussed above?


Jeremy Davis's picture

We have had a few people (more than usual) having issues with signups lately so it had crossed our minds that perhaps AWS had changed something. Your post confirms it so thanks very much. We will endeavor to update the Hub docs to align with the new process.

TBH I'm not sure whether this will affect existing deployments. I hope (and expect) not...! But we will have to check it out when we do our update/upgrade.

Using the Hub's "Restore this backup to a new cloud server" feature, the effect will be somewhat like launching a new clone, however instead of using the 'snapshot' data, it uses a TKLBAM backup.

So basically it starts a new server that matches the TKLBAM profile, it goes through it's normal boot and update process, then it restores the relevant TKLBAM backup.

Add new comment