TKLBAM restore issues

I think what you're missing is the concept of what directories in the appliance you are "allowed" to manipulate directly (e.g., anything in /etc, /usr/local, /var/www, etc.), vs what directories in the appliance are the responsibility of package management - touching these is naughty (e.g,. /usr/share). These "rules" aren't arbitrary, but are inherited from the Debian way of doing things. TKLBAM builds on these assumptions, so if you break them you will need to at least understand the consequences. I recommend you just don't break them.

In your case I'm guessing you installed your theme to the "wrong" place (e.g., /usr/share/drupal6/themes instead of /etc/drupal/6/sites/all/themes).

That didn't work because by default TKLBAM only backs up changes to directories that are not usually maintained by package management (e.g., apt-get) to avoid conflicts.

If you haven't done so already I recommend installing webmin-tklbam package:

apt-get install webmin-tklbam

To fix this problem, I recommend moving your theme on the backed up machine to the right location.

From the sound of it you also probably made the mistake of trying to overwrite files in the drupal6 Debian package by extracting a new Drupal6 tarball from upstream to the same location.

If you insist on maintaining drupal6 files directly rather than through package management add /usr/share/drupal6 to the overrides, but make sure you understand what this means. It's generally a bad idea to mess with files from package management as package upgrades will overwrite them. This is what /usr/local is for. It will be a bit more work, but if you really want to install Drupal6 from upstream, remove the drupal6 package (e.g., apt-get remove drupal6), and extract the tarball directly to /var/www.

Hope this helps!

Hi, Liraz.

Thanks for the quick reply and for clearing up what I was missing.

I do have my theme installed in the correct place:  /etc/drupal/6/sites/all/themes/zen

I think the errors were due to old cache data being used, since flushing the Drupal performance cache took care of them.

Unfortunately for me, I had no idea that I could update the Drupal core with the package manager.  For the last nine months, I have been manually updating the Drupal core on my TKL appliances as directed by the Drupal documentation.  Now, it makes sense as to why the Drupal core version reverted -- it was never backed-up!  I should have used the package manager to upgrade the Drupal core before running the TKLBAM restore.

Now that you explained what I was missing, letting the appliance handle application upgrades, I'm going to give TKLBAM another shot.  I'm not going to mess with this currently functioning system, but the first AMI termination will present an opportunity to restore everything the right way!

Thanks for your time,

-Derek

TBH I don't think that this thread is really that relevant to you.

I suggest you start your own thread. Post the output of the "turnkey-version" command and any other relevant details (e.g. where it is running, etc).

Then tell us what you are trying to accomplish; what you've tried already and what the result was. Posting links to other threads/posts (within TurnKey or elsewhere) is fine e.g. if you are trying to follow the steps from a particular post. If you get any error messages, paste them verbatim.

You have the theory correct. Mention of a path adds it to what get's backed up; a path proceeded with a '-' is excluded from backup.

All appliances inherit their TKLBAM profile from Core (many of them are actually just blank). FWIW you may find consulting the default Core profile useful?. In that you'll note that most of /var is not backed up; only some specific white-listed places...

If you would like to go over all the files that are included in your backup, use the '-s' (--simulate) switch. That will initiate a backup and collect all the files in /TKLBAM; but it will stop prior to creating the archives and uploading them. So you can essentially inspect the contents of your backup.

The only thing I'm not 100% sure about is whether --simulate always creates a full backup or whether it will create an incremental (if it's not yet time for a full backup)? You could use the '--full-backup' switch to ensure that it's a full backup.

So your command would look something like this:

tklbam-backup --full-backup 1D --simulate

I'm using the turnkey hub backups of atlassian in confluence system using the turnkey postgrees appliance. Backup works okay but I noticed that the size of the backup is incorrect. Checking the log files it seems /var/atlassian/application-data/confluence/ is not being backed up.

I understand that I have to add an override but can you confirm thi ssyntax

 /var/atlassian/application-data/confluence/
-/var/atlassian/application-data/confluence/backups/

the first line includes the confluence directory  and the second line excludes the backup folder ?

also my concern is that other dependent folders are not included any ideas how to establish if I have a full backup ?

Regards

Paul