ChristianG's picture

Hi Guys


I wonder if anyone is able to offer any assistance to this issue I have...  

I am attempting to do a one time server migration from turnkey-wordpress-14.2-jessie-amd64 to turnkey-wordpress-16.0-buster-amd64. 

I am leveraging the TKLBAM command "tklbam-backup --dump=bkp/" on the source machine, then when I am complete I will use the command "tklbam-restore bkp/".  

However I am getting this error on the source when running the backup, does anyone know how I can get this working?

UNCOMPRESSED BACKUP SIZE: 1.44 GB in 14172 files
Traceback (most recent call last):
  File "/usr/bin/tklbam-backup", line 510, in <module>
  File "/usr/bin/tklbam-backup", line 448, in main
  File "/usr/lib/tklbam/", line 273, in dump
    apply_overlay('/', path, self.extras_paths.fsdelta_olist)
  File "/usr/lib/tklbam/", line 72, in apply_overlay
    (olist_path, executil.mkarg(dst)))
  File "/usr/lib/python2.7/dist-packages/", line 66, in getoutput
    raise ExecError(command, exitcode, output)
executil.ExecError: non-zero exitcode (2) for command: tar --create --files-from=bkp/TKLBAM/fsdelta-olist | tar --extract --directory  'bkp/'
tar: bkp/TKLBAM/fsdelta-olist: Cannot stat: No such file or directory
tar: Error is not recoverable: exiting now
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

Out of interest I tried a restore and it's not restoing correctly obviously.  

Many thanks,


Jeremy Davis's picture

It looks like it's failing to find the directory for some reason. I suggest explicitly making the directory first. I also recommend using an absolute path (rather than a relative one). I.e. something like this:

mkdir /tklbam-dump
tklbam-backup --dump=/tklbam-dump

Also on the other end, seeing as you are making a significant jump in version, I would recommend that you restore as little as possible. I'd definitely skip packages (just manually install any additional packages you need), only restore the wordpress DB and /var/www/wordpress directory.

You'll need to recreate the wordpress DB user:

mysql -e "grant all privileges on wordpress.* to wordpress@localhost identified by '$(mcookie)'; flush privileges;"

And re-run the wordpress secret regen init hook.


Let us know how you go... :)

Jeremy Davis's picture

If you remove the hook script that it is complaining about, it should be auto replaced when you re-run the "get certificate" part. I.e.:

rm /etc/dehydrated/

Let me know how you go.

Jeremy Davis's picture

That looks good now. Although if you want to force it to try to get a new certificate (even if the current one isn't expired) then it accepts a '--force' (or '-f') argument. I.e.:

/usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper --help
Syntax: dehydrated-wrapper [--force|-f] [-r|--register] [--log-info|-i] [--help|-h]

Wrapper script for dehydrated on TurnKey Linux.
Provides a clean way to get SSL certs from Let's Encrypt's ACME server,
regardless of which webserver is being used or how it is configured.

This file is part of confconsole.

Environment variables:


        - dehydrated-wrapper will be very verbose (set -x)
        - INFO will be logged (default logging is WARNING & FATAL only)


    --force|-f     - pass force switch to dehydrated

                     This will force dehydrated to update certs regardless of
                     expiry. The included cron job does this by default (after
                     checking the expiry of /etc/ssl/private/cert.pem)

    --register|-r  - Accept Terms of Service (ToS) and register a Let's Encrypt
                     account. (Note if an LE account already registered, this
                     option makes no difference so is safe to always use).

                     Let's Encrypt ToS can currently be found here:

    --log-info|-i  - INFO will be logged (default logging is WARNING & FATAL

    --help|-h      - print this information and exit

For more info on advanced useage, please see

(And I just noticed a typo that I better go fix...).

Add new comment