Don Sanderson's picture

If I have multiple instances of an appliance, say 10 TKL LAMP servers, backing up to my one Hub account, how does the dashboard keep track of which is which?

Does it use the host name or some other criteria?

This is probably a dumb question but very important from the view of managing customers data.


BTW: The several appliances I've tried so far seem solid and professionally done, very nice work.

Don Sanderson's picture

root@CloudBox:~# tklbam-list
# ID  SKPP  Created     Updated     Size (GB)  Label
   1  No    2010-09-01  2010-09-01  0.02       TurnKey LAMP

To clarify my question a bit:

What would the output of the 'list' command show for my ten LAMP server backups?


Alon Swartz's picture

So, the example output from your post above, you are looking at Backup ID #1, with the label "TurnKey LAMP" (which you can customize).

BTW, each server also has it's own ID which you can see under the title Hub ID, and looks similar to b5ba1ba7-7d42-4ba9-9a28-e26f66a2890b. If your server (Amazon EC2 instance) is being backed up, then you'll notice that the backup record and server are inter-linked.

I hope this answers your question.

Don Sanderson's picture

Thanks Alon.

If I had several customers, each with a TKL LAMP server on their own hardware could I customize the backup 'Labels' to read something like:

Customer-1 Turnkey LAMP, Customer-2 Turnkey LAMP, Customer-3 Turnkey LAMP, Etc?

That way it would be very easy to sort it all out when a restore was needed.


Alon Swartz's picture

Of course, thats what the backup labels are there for :)

Alon Swartz's picture

Sorry for not being clear, I was referring to the Hub, not the TKLBAM tools / server itself.

Log into your Hub account and go to the Backups dashboard. Select the backup record you want to change, and click "Edit" where it displays the label.

Don Sanderson's picture

List the backup by typing "tklbam-list" on each server, this will tell you which backup is associated with that server.

Or you can trigger a backup at each server and note the backup time in the dashboard.

Alon Swartz's picture

As Don recommended, you can execute tklbam-list on each server, then note the Backup ID. Alternatively, you can find the backup_id in /var/lib/tklbam/hbr

Liraz Siri's picture

You don't need to go as low level as inspecting /var/lib/tklbam/hbr to get the backup ID. It's pretty much everywhere:

1) Webmin shows the backup ID.

2) It shows up in the configuration console main usage screen.

3) It's printed in the motd when you login via SSH.

4) You can get it via the cli:

TKLBAM:  Backup ID #2, Updated Wed 2011-03-09 10:06
Jeremy Davis's picture

but migration is part of what TKLBAM was intended for so hopefully you won't hit too many snags.

It'd be really great if you could document your efforts (a new thread or even on the dev wiki) so that will help others. Obviously make sure everything works before you destroy the old machines (I'd test in a VM).

Obviously if you have any issues start a new post (or you could use the same post if you intend to document your progress here in the forums).

Good luck :)

Don Sanderson's picture

Been looking for something like TKL for a while now.

I used to hand build appliances on an 'as needed' basis.

You do about 80% of my work for me, gotta love it! yes

Liraz Siri's picture

I'm curious, what kind of extra work do you have to do to customize TurnKey to satisfy your usage scenario?
Don Sanderson's picture

TurnKey itself seems nearly perfect.

Just leaves the installation and hardware/net setup.

Building/testing  the actual appliance always took the bulk of the time.

You guys are doing a fine job here.

Hope you all "Live long and prosper." and hopefully I'll be able to contribute

somewhere along the way.

L. Arnold's picture

I have hovered around this subject some.  I did run into on situation where TKLBAM could cross itself up.  This is the scenario.

If you Want to Duplicate a Build from VMware, it is quite convenient to use VMWare Converter.  This will give you a new Build that is in the same state as the last build.  The problem is that the TKLBam is also in the same state.

It is still a good way to do a One Time backup directly before a signigicant upgrade attempt because it will give you what you had just before.  (A Snapshot probably does the same).  This is not a good way to make a bunch of duplicate versions of the same to serve out to different clients (or your own domains).

Probably a "TKLbam" Remove routine would be in order, then regenerate a new one...  I am sure this is possible and may have been documented here before.

Often times systems like Joomla and Magento get significantly tuned and it would be nice to have a "base state" to spin new builds to.  I am guessing 4 command lines will allow this.

Unfortunately, I have not had good success doing Restores With TKLBam into new operating images.  It has worked quite well in a "restore" mode to the problematic build.  This does go against what is documented but it is worth being aware that a few directions may need to be tested in restore.

Great System no matter what caveats there may be.

L. Arnold's picture

It depends if you are taking the place of the old server or spinning a new one.

I would like to know how to do both "safely".  If replacing, I think just taking the old Backup ID works.

If spinning a new build it is critical to have a new Backup Id.

"remove-purge"  Is this to do w/ TKLBam?  I assume so.

thanks for posting!

Jeremy Davis's picture

But you guys are right. If it's a migration then keeping the old backup ID is probably desirable, but in a 'clone' you will want a unique ID. Surely there is an easy way to do it, hopefully Liraz (author of TKLBAM) will spot this  post and give us some pointers. Actually now I think of it I think there is an easy way to do it via the TKL Hub.

YFI  L. Arnold - apt-get remove <packagename> is the command line way to uninstall an app (basically the opposite of apt-get install <packagename>). But it will leave all the configuration files (usually found in /etc) in tact. If you wish to also remove all config info you need to use the --purge switch ie apt-get remove <packagename>. Hope that clarifies it for you.

Alon Swartz's picture

If you would like to re-initialize tklbam on a server, just use the following command. It will do the right thing, purge the current backup configuration, contact the Hub to setup a new backup id and storage location.

tklbam-init --force API_KEY

After performing a restore, a new backup (backup_id, etc.) will be registered in the Hub automatically - there is no need to mess around with TKLBAM's internals.

I hope the above clears up any misunderstandings. If something is still not clear, please ask.

L. Arnold's picture

Could you run the command before a "backup" rather than a "restore".  If you do a VMWare Clone you are not "restoring' so much as copying.  But you then want a new "Backup" image.  I assume you can run the command, then run a Backup and it will generate a new Id (as you note following a restore).

Sounds like the trick for a "spawning clone" (ie new Server based on Old Build).  This would be done, I assume, as soon as the new Clone is turned on and before any backup's take place.. 

Thanks for noting this!  We need to all line up for helping w/ the Wiki Documentation so the questions don't get asked too often.

L. Arnold

Alon Swartz's picture

Yes, when you force a reinitialization of TKLBAM all previous configurations are purged and you can do what ever you want (backup, restore, etc.) as if it was never associated with a backup id.

Add new comment