Ronan0's picture
Ronan0 - Thu, 2016/02/25 - 12:20

I had a production server backing up every hour on tklbam.

Now, I take a previous snapshot of this server from my cloud account (not AWS), and restore from latest tklbam backup of the production server to get an exact copy (for development and testing).

First, the restore took so long that the new server backed up an increment to the existing backup on top of the production servers increments - I presume that messes up my chain, and I should force a full backup asap?

Anyway to prevent this?

Secondly, what is the quickest way to STOP the second machine backing up? I thought chmod +r /etc/cron.daily/tklbam-backup  would do the trick, but it seemed not to.

But I would really like to re-initialise, and create a new back up ID specifically for the second server. Can anyone tell me how to do that? Do I just re-intitialise? I.e. tklbam-init Or do I need to get rid of the old initialisation parameters first?

Thanks.

Forum: 
Support
Tags: 
tklbam migration
Jeremy Davis's picture

Jeremy Davis - Sun, 2016/03/06 - 01:31
A new server should automatically create a new backup ID, and that's how it's always worked for me...

Any new incremental backup in your chain should only have come from the server that is being backed up; not the server being restored to (assuming that they are different machines obviously).

By default new servers will only do a full backup once per month. But if you have configured daily incremental backups and want ot disable it do this: 

chmod -x /etc/cron.daily/tklbam-backup
. FWIW the command you used gave the file read permissions... With chmod; '+' = add, '-' = remove, 'x' = execute, 'w' = write & 'r' = read.

Like I said, the new server should automagically create a new id.

Ronan0's picture

Ronan0 - Mon, 2016/03/07 - 10:22

What if the snapshot used for the restore is not a brand new server, but a snapshot of the server to be restored, only a month or so back? Then it will keep the same ID, won't it? In that case, is there anyway to change it? Thanks.

Jeremy Davis's picture

Jeremy Davis - Wed, 2016/03/16 - 06:24
If you use a snapshot then the machine is essentially a clone. If you plan on using TKLBAM for backups, I recommend that you actually restore your backup to a new server (not made from a snapshot). That way you are also testing your backup at the same time as migrating your data. That will allow you to be sure that everything that you need in your backup is there. TKLBAM is a pretty good system and should work flawlessly, however it relies on number of assumptions so it's best to test your backups regularly.

You may already be aware of this, but just in case: Keep in mind that whilst snapshots can be really handy, they can be volatile and occasionally suffer from data corruption. Therefore that are not a backup replacement.

If you still want to re-initialise this server so it starts using a new backup ID, you can do that by removing the current TKLBAM connection and re-initialising it. Have a look at this post.

Ronan0's picture

Ronan0 - Wed, 2016/03/16 - 10:59

Thanks.

I didn't know that back-ups had a higher integrity than a snapshot done on a properly shut down server. Thanks for that.

So just to be absolutely clear - if I am to start from a new server, the packages that I need for my application to run are (1) the Java JDK, (2) Gradle, (3) MySQL.

But, TKLBAM does not manage these packages, so I need to manually reinstall these first, and then do the restore?

Essentially, I was using snapshots to avoid this extra work. 

Thanks again for the input.

Jeremy Davis's picture

Jeremy Davis - Fri, 2016/03/18 - 03:13
If you are doing "proper" snapshots (i.e. with the machine shutdown) then they are much more reliable and possibly as robust as tklbam backups (although personally I am still wary and they are huge and not transferable). IMO a TKLBAM backup is better. It also allows you to migrate your data to another machine (e.g. a local VM) for development/staging/testing, without it being a clone (which can cause issues sometimes).

WRT to your question, if additional packages are package managed and come from the Debian (or TurnKey) repos then TKLBAM can deal with that (it will auto install them). However if they come from a 3rd party repo or are installed via an alternate (to apt) method then you will need to install them manually.

Having said that if you plan on using TKLBAM for backups then you can actually script that part and use tklbam-hooks to automate the install on restore. Check out the docs and the (quite dated but still relevant) announcement blog post.

Add new comment