Prepare a stock centos HN to do vzdumps using LVM snapshots

Situation:

- Stock Centos 4 system with OpenVZ kernel + utilities installed. One big /vz partition, using LVM.

Trying to make a backup using:

vzdump --dumpdir /var/ --snapshot 101
Error message received:
Insufficient free extents (1) in volume group
VolGroup00: 16 required
What does that mean?

It means that you don't have enough free space in the VG (Volume Group) to create an LVM snapshot.

What is the solution? Reduce the size of one partition, then resize one LV (logical volume). This is easily done if you don't have only one big / partition. I usually always make a separate partition for /var and for /vz.

To determine what logical volume needs to be resized, you can use the df -h command. Mine showed:

/dev/mapper/VolGroup00-LogVol05
119G 16G 99G 14% /vz

To resize it:

  1. Make backups of your VM to be sure
  2. Stop the vz service (service vz stop)
  3. umount /vz
  4. e2fsck -f /dev/VolGroup00/LogVol05
  5. Use resize2fs /dev/VolGroup00/LogVol05 110G
  6. Use lvresize to reduce the LV sizey by 2 GB:lvresize --size -2G /dev/VolGroup00/LogVol05
Optionnaly, you can resize your FS to match the size of the LV, using no size arguments to ext2resize:
  1. e2fsck -f /dev/VolGroup00/LogVol05
  2. resize2fs /dev/VolGroup00/LogVol05
I have not re-tested this procedure itself from the beginning (I don't have a test system here), but it should be pretty safe. Please leave comments if you try this.

If you need to know how big are your LV : lvdisplay.
If you need to know how big are our VG: vgdisplay. This also tells the free space in the VG.

You can not try to use lvm snapshots with vzdump.

Comments

Post a Comment

Popular posts from this blog

General linux performance troubleshooting

Here's a list of commands that you should execute and then share the output to someone who can help you figure out what resource is the bottleneck in your system. Note, it requires the  sysstat  and  procps  packages (ubuntu and RHEL and its derivatives): uptime vmstat 1 10 iostat -xN 2 10 mpstat -P ALL 3 10 pidstat 1 10 free -mw (or free -m, if your OS doesn't support -w)  uptime is to see the load averages on the system. vmstat is mostly used to tell if the system is swapping or not. If you see significant numbers in the 'si' and 'so' columns, your system is most likely swapping (using the hard drive as RAM), which usually slows performance a lot. iostat is mostly used to determine if your disk subsystem is not able to cope with the load. If you see one or more lines that shows 100 or close almost constantly, it is probably the case.  If it is your swap volume, you probably saw numbers in the 'si' and 'so' columns in the  vmsta
Read more

Networker automated recovery testing using the REST API - introduction

One feature that is lacking from Networker, compared to some of its competitors, is the built-in automatic recovery testing. However, when there's an API, there is a way.  Networker's REST API is not perfect, but it allows the backup administrator to perform queries about Networker resources (objects). As my workload is going up, I realize that one of the tasks that I tend to skip the most is the periodical recovery tests.  Don't forget that a a backup that is not tested should be considered non-successful. I also found out that my recovery tests were not diverse enough. When I started this project, I knew a little bit about REST APIs, and nothing about JSON processing. With the Networker REST API documentation, and the help of a friend and Networker Support staff, I was able to create HTTP queries with Postman,  cURL and jq . Once I got the queries that I needed, I put them in a bash script that would somehow select one backup, and then restore it. My first attempt
Read more

Networker automated recovery testing using the REST API - first script

I have worked a lot on my automated recovery script recently and finally got to a version that is a really good proof of concept and that I'm not scared to publish.  Plus, I have created a Gitub repo for documentation, issue management and, of course, Git features. The script is not perfect but it is even better than what I was planning when I wrote my first post on the topic: A lot of checks have been put in place to make sure all variables are provided, and in the right format There is an inline help with -h The script chooses a backup randomly amongst all the available backups, not only the 30 last ones It only requires bash, cURL and jq, on a machine that has access to the Networker REST API Only tested on RHEL 6 for now The script is not complete (I already created more than 10 issues to add features, improve current features or fix things), but it is a very good start for an organisation that wants to make recovery tests easier. The Github repo will also allow
Read more