You are here
Hi all
A junior web developer broke all our sites using the root account on our Turnkey WordPress install on the TurnkeyHub - no problem I thought I can just roll back to a back up using tklbam-restore 1.
However after trying 5 different back ups we were getting various different MYSQL errors such as:
ERROR 1005 (HY000) at line 166: Can't create table
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql
/mysql.sock' errno 32 broken pipe
Once I had tracked down the issue which was that they had changed the MySQL directory permissions why didn't full restores change these permissions back?
I have used both vps.net and linode before and you can power down the instance, restore a back up and be up and running again EXACTLY like you were within 3 mins max!
Thanks
So you restored to an existing instance? Or to a clean install?
I'm assuming to your existing instance (because of your wording - and that a restore/migration to a new instance should have worked fine).
But I guess it's somewhat irrelevant. I am inclined to agree with you that a backup restore should overwrite all current data. So perhaps it's a bug. Or maybe the devs have some reason for this behaviour. Have to wait to hear from one of them...
In the meantime you could file a bug report if you want.
Yes this was a restore to our
Yes this was a restore to our current instance and not a new one.
Thanks for your agreement that the restore should act more as a bare metal back up than some weird incremental / skips system files type version.
I will try and do a bug report now but would appreciate a response here too.Looks like I need to register somewhere else then spend time trying to file a bug report which for something that we are paying for and is trying to compete with other VPS providers out there I don't think is acceptable. I will await an official response here.
Thanks
Fair enough
But just remember that you aren't paying TKL for anything much! The only costs associated with TKLBAM are from Amazon (TKL get nothing from tthe money you pay Amazon for S3) and if you are using a small or medium AWS instance then TKL are only getting 10% of your total costs (micro is still surcharge free AFAIK). All the development work done by the TKL devs including TKLBAM, the Hub, the 40+ appliances and all the other stuff (including the hosting of this site) they donate freely to the community so it's nothing like anything else you get from another VPS. Even the money they raised initially (from donations) they put back into the project via the contest they ran (they put some of their own personal cash into it too).
The devs are happy to hear constructive feedback, but remember that this is a free, open source project so I think it's fair to give credit where credit is due. Also in fairness, TKLBAM does things that simply aren't possible or available in the sort of backup scenerio it sounds like you've used previously (or anything I've ever used before). TKLBAM allows you to develop in a VM, migrate it to a bare-metal install, change your mind and migrate it into the cloud (AWS or any other VPS provider that supports TKL) and then back again if you like. It is completely havdware (or virtualisation platform) agnostic.
Obviously you have it sorted now, but until this is addressed (for future reference) it's probably much quicker and easier to just launch a new instance and migrate your data into that (using TKLBAM) that muck around repairing an existing (broken) one. I suspect that's why a bug like this has been a part of TKLBAM for so long without being picked up previously.
I am more than appreciative
I am more than appreciative of what TKL are doing but for people who go for medium or more then you are whether you like it or not competing against the likes of linode.com, vps.net (not as good as they were) and then up from there (in terms of price) Rackspace etc.
In terms of back ups - by offering both full and incremental back ups as you previously agreed it should be possible to roll back if system changes bring down your instance.
Also fyi Linode.com and others allow at least as much as TKLBAM seems to provide so far if nore more hence my post.
You seem to misunderstand
TKL isn't a VPS provider, it's an OS (with a few extra goodies). An OS that can be downloaded in a range of different formats to run locally (on hardware or virtualised) or in the cloud on any VPS provider that is willing to offer the images. TKL is not competeing with Linode or VPS.net (or any other VPS provider) - Amazon is. IIRC TKL images are even available on VPS.net (at least they were at one point).
Perhaps where your confusion is arising is that currently the Hub only supports AWS and TKLBAM requires an active Amazon account (although you don't need to use it - backups can be done locally, or to your own remote storage, or to another provider's storage - using Rsync or SFTP etc). TKL Hub being linked with AWS is just a matter of pragmatics. No other VPS provider has the global coverage and scope that AWS have so until VPS providers can agree on a common (and preferably open source) API, it is simply not practical for an unpaid 2 man crew (ie the core TKL devs: Alon and Liraz) to support them all via the Hub.
From my understanding the devs are happy to work with any VPS provider so they too can offer TKL images to their customers. But as I said above, until there is some uniformity amoung providers it's just not practical for the Hub to support them all.
TKLBAM actually makes it easy to migrate from one cloud provider to another (provided that they offer TKL images in the first place - although even then, one community member had TKL running on RackSpace at one point - desite the fact that RackSpace don't officially support it).
And yes I agree that ideally it'd be great if TKLBAM could be used to restore a current server to a previous state - as you were hoping for. My agreement was around the fact that IMO your usage scenario could and should be accommodated. I can't see any reason why not (although perhaps Alon or Liraz have one?) And I also agree that it would make the user experience more complete.
Personally that's not how I use TKLBAM though. I have my own quick and dirty local backups for general use. I run all my TKL instances locally and use TKLBAM more for migrating from one server to another (sometimes I work in a local VirtualBox instance on my laptop or on my Proxmox server at home, then migrate to my Proxmox server at work, or vice-versa). I don't host anything on AWS but it's great to have available for disaster recovery should I need to (re)launch a server due to hardware failure. Within minutes I can have a fully functioning server with all the data ready to go, even if my hardware is dead and/or there is a serious power failure onsite.
Thanks for your further
Thanks for your further detailed reply Jeremy.
I understand what TKL is and offers but in my opinion once this is linked to Amazon via the hub paid for service and then TKLBAM the hub naturally starts being compared with other cloud based systems / VPS providers.
Hopefully the functionlity I expected via TKLBAM can be added soon so more people feel confident with the all in one hub solution and it can continue to grow which will benefit all
Agreed!
Let's hope so! :)
Question on details of the backup-restore
I was reading this topic, because I believe I have a similar question/clarification.
What are the limitations of restoring a TKLBAM backup? Specifically what I mean is, if I restore a TKLBAM backup, is my system in the EXACT same configuration with the EXACT same files, folders, configuration files and permissions as the backup?
Here's a use case to hopefully clarify further:
I use a tklcore image to create an appliance - TKLCORE APPLIANCE 1. I make a few changes to it and then make a TKLBAM backup of it - BACKUP 1.
If I created another tklcore appliance - TKLCORE APPLIANCE 2 and don't modify anything. I'm assuming that I could do a restore of BACKUP 1 to that appliance and essentially make it a clone of TKLCORE APPLIANCE 1 (from the time it was backed up).
Now, If I created another tklcore appliance - TKLCORE APPLIANCE 3 and I made a bunch of modifications to it, load packages, change configuration files, change file permissions, add users, etc... - and then I wanted to "restore" it to the EXACT state of BACKUP 1, is it possible to do that by simply doing a restore of BACKUP 1?
Or is that not how the TKLBAM backups are designed to work?
Thanks!
-Brian
That is a valid scenario
But there are some limitations. Also I would be a little wary of the word "EXACTLY".
TKLBAM is a 'smart' backup which only backs up specific areas of the filesystem. Assuming that you only have data in places where TKLBAM is looking for it then your appliance 2 will be basically the same as appliance 1. However if you have custom debs or software installed from a third party repo, those apps will need to be installed separately (TKLBAM has allowance for pre and post backup/restore hooks which can be customised to do any additional task you wish).
Some settings (such as networking settings) will remain specific to the individual machine.
As for appliance 3, depending on what you do to it prior to restoring the backup then it is likely that appliance 3 post restore will be a hybrid of appliances 1 and 3. Eg if you install some additional software TKLBAM will not uninstall it - but it will reinstall additional software that is present in appliance 1 but not appliance 3 (assuming that it comes from default repos). Additonal users you create on appliance 3 will not be removed (basically anything in appliance 3 that is not present in appliance 1 will remain unchanged). If you want appliance 3 to be the same as appliances 1 and 2, then I would recommend reinstalling appliance 3 (with vanilla core) and then restore your backup to it.
TKLBAM is not like a snapshot of a previous state (although that functionality is supported separately by the Hub on EC2 instances with EBS volumes, many 3rd party virtual environments also offer that level of 'rollback'). TKLBAM is a 'smart' backup of all the data that you would reasonably want backed up (assuming that you follow the Debian file system heirarchy and don't put things in areas of the FS designed to be handled by package management) and when restored somewhat merges that data with what exists. Files that exist in both will be overwritten by the backup, but files that exist on the FS but not in the backup will remain AFAIK.
The usage scenarios TKLBAM was intended for was primarily for disater recovery and migration (ie restore backup to a clean install) or quick rollback of relevant data (eg for a website hosted on the LAMP appliance).
I suggest that you do some testing yourself so you can see it's strengths and weaknesses. If you keep the amount of data to a minimum then it is pretty qucik and cheap (it compresses the data prior to upload and AWS S3 is ~$0.14/GB/mth. I currently have a couple of appliances whose backups literally cost me $0.02/mth!
That is what I suspected
Thank you for the reply!
That is pretty much what I suspected, that the TKLBAM backup does NOT perform like a snapshot. Primarilly, that it doesn't remove anything that may have been added beyond the contents of the backup. Essentially, it would create a hybrid of the 2 systems - like you mentioned.
Ok, as long as I know that then I'll just re-install and do the restore onto the clean install. I was hoping that I may be able to save a step and not have to re-install, but I see the logic of the backups now.
And, I did see that the EC2 instances of the TKL appliances do have true "Snapshot" capabilities built into the core that would allow a true "roll back" or clone at any time. Good Stuff.
-Brian
Add new comment