Confusion, concern over projected Amazon billing

Hi Robin, sorry to hear you've been having some hassles with it all.

So to use AWS Free Tier you need to enable EBS backed instances. Micro instances (and therefore the Free Tier) are not available S3 backed. This leaves you wiith 2 options: Enable the Buget plan in the Hub (ie EBS backed volumes - $20/mth charge) or invite a friend which will give you free access to EBS backed Micro instances. (PS these links only work when logged in to the Hub).

When you launch your server you need to specify the server size on the Launch page. If you haven't taken either of the above steps Micro instance (or EBS backed volumes) won't be allowed. IIRC Micro volumes are only available as an option once one of the steps in the first paragraph have been taken. Perhaps this is how you accidentally launched Small servers rather than Micro? I'd be interested if you go back and try to launch a Micro instance again (before you enable EBS/Micro) to see if there is anything that you can think of that would make this more obvious. I can't because I have EBS volumes enabled (I guess I could set up a new account...)

To get yourself back on the Free Tier you will need to manually create Micro instances (after taking the steps in top paragraph) and migrate your data across. TKLBAM would be the easiest way to do this. Make sure though that everything works in your new Micro instances before you destroy your current Small instances (once you destroy them/stop them all the data is gone forever - except of cource what is stored via TKLBAM).

Sorry about the confusion. What needs to change in the documentation/help/Hub info to make this clearer? From where I sit it seems relatively clear, but obviously not clear enough! Be great if we can avoid others having this issue in the future (as much as possible anyway...).

As for the AWS charges, whatever you have used, you will be charged by AWS. TKL has no control over that and you will have to discuss that with Amazon (although I wouldn't hold my breath if I were you). TKL do collect a 10% premium on AWS charges under the Hobby plan but that too is collected by AWS. If you contact the core devs (Alon and Liraz) via the feedback feature (blue button, left hand side when logged into the Hub) they may be willing to somehow credit you the TKL premium as a goodwill gesture, but I can't guarantee that (I have nothing to do with that side of things, just do a bit of dev work and man the forums). Also just a heads up (re sending Feedback) I know Alon and Liraz make a big effort to be responsive to the Hub Feedback but they are deep in a development cycle at the moment so you may need to be a little patient. Feel free to post back here (or contact me via my contact page) if you haven't had any response after a while.

Thanks for your reply. I will return another time to post what I think the source(s) of my confusion was (were) -- there are 3 factors which I think played a part in creating this mess.

Meanwhile, I am trying to rapidly migrate to micro instances to put an end to the charges; however, when attempting to user tklbam to backup one of the existing instances, I get an error, which I have not been able to locate help for in the forum. The error text is as follows:

...

File "/usr/lib/tklbam/hub.py", line 183, in _api
return API.request(method, self.API_URL + uri, attrs, headers)
File "/usr/lib/tklbam/hub.py", line 127, in request
raise Error(c.response_code, name, description)
hub.Error: (404, 'BackupArchive.NotFound', 'Backup profile archive not found: turnkey-lapp-11.3-lucid-x86')

I'd appreciate any help I can get to help me quickly make this migration.

Unfortunately PostgreSQL (one of the 'P's in LAPP) isn't currently supported by TKLBAM (see here).

But all is not yet lost... It's just not as auomagical as it could (should?) be and will involve a little coding/hacking on your behalf (if you want to use TKLBAM).

So this is what you'll need to do if you want to force TKLBAM to backup/restore your LAPP appliance (untested though, so make sure you test fully before you assume I'm not leading you astray - obviously I'm not intentionally, but I haven't tested this). I'd strongly suggest that you closely document this process as then you can back track if something doesn't work as expected and you can share with others you may wish to follow in your footsteps.

• First read this blog post (and I suggest also acompanying comments) and ideally the TKLBAM docs.
• To be on the safe side I'd be inclined to manually dump your DB (just in case...) You can do this once you figure it out below, or perhaps even using PHPPgAdmin (available via port 12322 - I assume it does that, but not sure).
• Hack your LAPP appliance to make it think it's Core (rather than LAPP - so you bypass that error). See this post specifically on how to do that. (If you haven't already, I strongly suggest you read the posts above so you understand the repercussions of doing this.
• Configure TKLBAM hookscripts (as per the above mentioned Blog post) to dump and restore the PostgreSQL DB. You'll need to consult google/Ubuntu forums/docs (TKL v11.x is based heavily on Ubuntu 10.04) to work out how to do this. Personally I'd stop PostgreSQL prior to dump and restore to reduce chances of DB corruption (and restart it afterwards).
• Configure TKLBAM to include/exclude the desired files/folders (including the dumped DB). If size isn't an issue then you really only need to make sure that your desired data is included. I would imagine most of it would be by default (because if you have followed the step mentioned above you have tricked TKLBAM to think your LAPP appliance is actually Core - which is the basis of all TKL appliances). Read about the steps to do this here, here and here. Obviously make sure that you include your DB dump file (or put it somewhere that is included by default).
• Test to make sure it all works as expected...
• Post back here with your notes inc TKLBAM hook script etc. :)

OTOH you could still just manually migrate it (manually dump DB either via commandline or PHPPgAdmin? - and rsync data & DB across). Although this may seem like an easier plan, I think the effort to set up TKLBAM to work would pay off (as then you can keep using it for backups). It would also healp others and may also push the development of official PostgreSQL support.

Good luck with it. Unfortunately I won't be able to help much further for the next day or 2 as I'm about to head off, but I'll do what I can when I'm back online.