Christophe Eymard's picture

As stated in the title, my tklbam-restore is already a few hours in for a 6 Gigs backup, and I'm starting to think that this is a little too much.

I have absolutely no clue as to where to start to investigate what is happening.

I did the following thing :

  1. Install OpenVZ template in proxmox
  2. Connect to it as root
  3. Run tklbam-init with my API key
  4. Run tklbam-restore 7
  5. ... not profit ??
  6. Still waiting :)

I would appreciate any help from anyone.


Edit: Forgot to mention that the download from Amazon S3 went ok, I'm stuck at a message displaying "Last full backup the ..." where it just sits there.

Jeremy Davis's picture

As the restore downloads and unpacks to /tmp if you have a sizeable backup and/or a small container and there is insuffient room, the TKLBAM restore will hang. This is a known issue. The only real universal solution is for the devs to make TKLBAM check for this and to error with an explanation (which I'm sure they'll do when they get a chance).

Assuming this is the problem - One workaround is just to make your container bigger. Alternatively you could create an external bind mount to the /tmp dir of your container - ie use the HDD space of your host OS to store the container's /tmp folder (check OVZ docs for how to do this, I've done it before but don't remember the steps OTTOMH).

Liraz Siri's picture

I'll bet it's probably just TKLBAM shuffling bits back and forth from S3. That can take time and duplicity doesn't use much bandwidth while it's doing that. To see the load on the network I like to use nload:

apt-get install nload
Christophe Eymard's picture

I'll try nload, but I thought that when saying "Last Full backup", it meant that already was already downloaded.

About the disk space, I had like a 5 gigas backup that I tried to restore on a 100 Giga OpenVZ appliance.
Also, this was in a server bay with an outstanding internet connection.

Add new comment