You are here
Christophe Eymard - Wed, 2012/02/29 - 18:13
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 :
- Install OpenVZ template in proxmox
- Connect to it as root
- Run tklbam-init with my API key
- Run tklbam-restore 7
- ... not profit ??
- Still waiting :)
I would appreciate any help from anyone.
Cheers.
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.
Forum:
Have you run out of room?
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).
Probably a network thing...
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:
I'll try nload, but I thought
I'll try nload, but I thought that when saying "Last Full backup", it meant that already was already downloaded.
Add new comment