Nova-volume is the service that allows you to give extra block level storage to your OpenStack Compute instances. You may recognize this as a similar offering from Amazon EC2 known as Elastic Block Storage (EBS). However, nova-volume is not the same implementation that EC2 uses today. Nova-volume is an iSCSI solution that employs the use of Logical Volume Manager (LVM) for Linux. Note that a volume may only be attached to one instance at a time. This is not a ‘shared storage’ solution like a SAN of NFS on which multiple servers can attach to.
Before going any further; let's discuss the nova-volume implementation in OpenStack:
The nova-volumes service uses iSCSI-exposed LVM volumes to the compute nodes which run instances. Thus, there are two components involved:
lvm2, which works with a VG called "nova-volumes" (Refer to http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) for further details)
open-iscsi, the iSCSI implementation which manages iSCSI sessions on the compute nodes
Here is what happens from the volume creation to its attachment (we use euca2ools for examples, but the same explanation goes with the API):
The volume is created via $euca-create-volume; which creates an LV into the volume group (VG) "nova-volumes"
The volume is attached to an instance via $euca-attach-volume; which creates a unique iSCSI IQN that will be exposed to the compute node
The compute node which run the concerned instance has now an active ISCSI session; and a new local storage (usually a /dev/sdX disk)
libvirt uses that local storage as a storage for the instance; the instance get a new disk (usually a /dev/vdX disk)
For this particular walkthrough, there is one cloud controller running nova-api, nova-scheduler, nova-objectstore, nova-network and nova-volume services. There are two additional compute nodes running nova-compute. The walkthrough uses a custom partitioning scheme that carves out 60GB of space and labels it as LVM. The network is a /28 .80-.95, and FlatManger is the NetworkManager setting for OpenStack Compute (Nova).
Please note that the network mode doesn't interfere at all with the way nova-volume works, but networking must be set up for for nova-volumes to work. Please refer to Chapter 7, Networking for more details.
To set up Compute to use volumes, ensure that nova-volume is installed along with lvm2. The guide will be split in four parts :
A- Installing the nova-volume service on the cloud controller.
B- Configuring the "nova-volumes" volume group on the compute nodes.
C- Troubleshooting your nova-volume installation.
D- Backup your nova volumes.
This is simply done by installing the two components on the cloud controller :
apt-get install lvm2 nova-volumeFor Ubuntu distros, the nova-volumes component will not properly work (regarding the part which deals with volumes deletion) without a small fix. In dorder to fix that, do the following :
sudo visudo
Then add an entry for the nova user (here is the default sudoers file with our added nova user) :
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
# Host alias specification
# User alias specification
# Cmnd alias specification
nova ALL = (root) NOPASSWD: /bin/dd
# User privilege specification
root ALL=(ALL) ALL
# Allow members of group sudo to execute any command
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL
#
#includedir /etc/sudoers.d
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
That will allow the nova user to run the "dd" command (which empties a volume before its deletion).
Configure Volumes for use with nova-volume
If you do not already have LVM volumes on hand, but have free drive space, you will need to create a LVM volume before proceeding. Here is a short run down of how you would create a LVM from free drive space on your system. Start off by issuing an fdisk command to your drive with the free space:
fdisk /dev/sdaOnce in fdisk, perform the following commands:
Press ‘
n'to create a new disk partition,Press
'p'to create a primary disk partition,Press
'1'to denote it as 1st disk partition,Either press ENTER twice to accept the default of 1st and last cylinder – to convert the remainder of hard disk to a single disk partition -OR- press ENTER once to accept the default of the 1st, and then choose how big you want the partition to be by specifying +size{K,M,G} e.g. +5G or +6700M.
Press
't', thenselect the new partition you made.Press
'8e'change your new partition to 8e, i.e. Linux LVM partition type.Press ‘
p'to display the hard disk partition setup. Please take note that the first partition is denoted as /dev/sda1 in Linux.Press
'w'to write the partition table and exit fdisk upon completion.Refresh your partition table to ensure your new partition shows up, and verify with fdisk. We then inform the OS about the table partition update :
partprobeAgain :fdisk -l (you should see your new partition in this listing)Here is how you can set up partitioning during the OS install to prepare for this nova-volume configuration:
root@osdemo03:~# fdisk -l
Device Boot Start End Blocks Id System /dev/sda1 * 1 12158 97280 83 Linux /dev/sda2 12158 24316 97655808 83 Linux /dev/sda3 24316 24328 97654784 83 Linux /dev/sda4 24328 42443 145507329 5 Extended /dev/sda5 24328 32352 64452608 8e Linux LVM /dev/sda6 32352 40497 65428480 8e Linux LVM /dev/sda7 40498 42443 15624192 82 Linux swap / Solaris
Now that you have identified a partition has been labeled for LVM use, perform the following steps to configure LVM and prepare it as nova-volumes. You must name your volume group ‘nova-volumes’ or things will not work as expected:
pvcreate /dev/sda5 vgcreate nova-volumes /dev/sda5
Since you have created the volume group, you will be able to use the following tools for managing your volumes:
euca-create-volume
euca-attach-volume
euca-detach-volume
euca-delete-volume
![[Note]](../common/images/admon/note.png) | Note |
|---|---|
If you are using KVM as your hypervisor, then the actual device name in the guest will be different than the one specified in the euca-attach-volume command. You can specify a device name to the KVM hypervisor, but the actual means of attaching to the guest is over a virtual PCI bus. When the guest sees a new device on the PCI bus, it picks the next available name (which in most cases is /dev/vdc) and the disk shows up there on the guest. |
Installing and configuring the iSCSI initiator
Remember that every node will act as the iSCSI initiator while the server running nova-volumes will act as the iSCSI target. So make sure, before going further that your nodes can communicate with you nova-volumes server. If you have a firewall running on it, make sure that the port 3260 (tcp) accepts incoming connections.
First install the open-iscsi package on the initiators, so the compute-nodes only :
apt-get install open-iscsiThen on the target, which is in our case the cloud-controller, the iscsitarget package :
apt-get install iscsitargetThis package could refuse to start with a "FATAL: Module iscsi_trgt not found" error. This error is caused by the kernel which does not contain the iscsi module's source into it ; you can install the kernel modules by installing an extra pacakge :
apt-get install iscsitarget-dkms(the Dynamic Kernel Module Support is a framework used for created modules with non-existent sources into the current kernel)You have to enable it so the startut script (/etc/init.d/iscsitarget) can start the daemon :
sed -i 's/false/true/g' /etc/default/iscsitargetThen run on the nova-controller (iscsi target) :
service iscsitarget startAnd on the compute-nodes (iscsi initiators) :
service open-iscsi startConfigure nova.conf flag file
Edit your nova.conf to include a new flag, "–iscsi_ip_prefix=192.168." The flag will be used by the compute node when the iSCSI discovery will be performed and the session created. The prefix based on the two first bytes will allows the iSCSI discovery to use all the available routes (also known as multipathing) to the iSCSI server (eg. nova-volumes) into your network. We will see into the "Troubleshooting" section how to deal with ISCSI sessions.
Start nova-volume and create volumes
You are now ready to fire up nova-volume, and start creating volumes!
service nova-volume startOnce the service is started, login to your controller and ensure you’ve properly sourced your ‘novarc’ file. You will be able to use the euca2ools related to volumes interactions (see above).
One of the first things you should do is make sure that nova-volume is checking in as expected. You can do so using nova-manage:
nova-manage service listIf you see a smiling ‘nova-volume’ in there, you are looking good. Now create a new volume:
Using euca2ools :
euca-create-volume -s 22 -z nova(-s refers to the size of the volume in GB, and -z is the default zone (usually nova))Using the python-novaclient :
nova volume-create --display_name "my volume" 22You should get some output similar to this:
VOLUME vol-0000000b 22 creating (wayne, None, None, None) 2011-02-11 06:58:46.941818
You can view that status of the volumes creation using ‘euca-describe-volumes’. Once that status is ‘available,’ it is ready to be attached to an instance:
euca-attach-volume -i i-00000008 -d /dev/vdb vol-00000009(-i refers to the instance you will attach the volume to, -d is the mountpoint (on the compute-node ! and then the volume name.)
By doing that, the compute-node which runs the instance basically performs an iSCSI connection and creates a session. You can ensure that the session has been created by running :
iscsiadm -m sessionWhich should output :
root@nova-cn1:~# iscsiadm -m session tcp: [1] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-0000000b
If you do not get any errors, it is time to login to instance ‘i-00000008′ and see if the new space is there.
KVM changes the device name, since it's not considered to be the same type of device as the instances uses as it's local one, you will find the nova-volume will be designated as "/dev/vdX" devices, while local are named "/dev/sdX".
You can check the volume attachment by running :
dmesg | tailYou should from there see a new disk. Here is the output from ‘fdisk -l’ from i-00000008:
Disk /dev/vda: 10.7 GB, 10737418240 bytes 16 heads, 63 sectors/track, 20805 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0×00000000 Disk /dev/vda doesn’t contain a valid partition table Disk /dev/vdb: 21.5 GB, 21474836480 bytes <—–Here is our new volume! 16 heads, 63 sectors/track, 41610 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0×00000000Now with the space presented, let’s configure it for use:
fdisk /dev/vdbPress ‘
n'to create a new disk partition.Press
'p'to create a primary disk partition.Press
'1'to denote it as 1st disk partition.Press ENTER twice to accept the default of 1st and last cylinder – to convert the remainder of hard disk to a single disk partition.
Press
't', thenselect the new partition you made.Press
'83'change your new partition to 83, i.e. Linux partition type.Press ‘
p'to display the hard disk partition setup. Please take note that the first partition is denoted as /dev/vda1 in your instance.Press
'w'to write the partition table and exit fdisk upon completion.Lastly, make a file system on the partition and mount it.
mkfs.ext3 /dev/vdb1 mkdir /extraspace mount /dev/vdb1 /extraspace
Your new volume has now been successfully mounted, and is ready for use! The ‘euca’ commands are pretty self-explanatory, so play around with them and create new volumes, tear them down, attach and reattach, and so on.
If the volume attachment doesn't work, you should be able to perform different checks in order to see where the issue is. The nova-volume.log and nova-compute.log will help you to diagnosis the errors you could encounter :
nova-compute.log / nova-volume.log
ERROR "15- already exists"
"ProcessExecutionError: Unexpected error while running command.\nCommand: sudo iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000001 -p 10.192.12.34:3260 --login\nExit code: 255\nStdout: 'Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-00000001, portal: 10.192.12.34,3260]\\n'\nStderr: 'iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-00000001, portal:10.192.12.34,3260]: openiscsiadm: initiator reported error (15 - already exists)\\n'\n"]
This errors happens sometimes when you run an euca-detach-volume and euca-attach-volume and/ or try to attach another volume to an instance. It happens when the compute node has a running session while you try to attach a volume by using the same IQN. You could check that by running :
iscsiadm -m sessionYou should have a session with the same name that the compute is trying to open. Actually, it seems to be related to the several routes available for the iSCSI exposition, those routes could be seen by running on the compute node :
iscsiadm -m discovery -t st -p $ip_of_nova-volumesYou should see for a volume multiple addresses to reach it. The only known workaround to that is to change the "–iscsi_ip_prefix" flag and use the 4 bytes (full IP) of the nova-volumes server, eg :
"–iscsi_ip_prefix=192.168.2.1You'll have then to restart both nova-compute and nova-volume services.
ERROR "Cannot resolve host"
(nova.root): TRACE: ProcessExecutionError: Unexpected error while running command. (nova.root): TRACE: Command: sudo iscsiadm -m discovery -t sendtargets -p ubuntu03c (nova.root): TRACE: Exit code: 255 (nova.root): TRACE: Stdout: '' (nova.root): TRACE: Stderr: 'iscsiadm: Cannot resolve host ubuntu03c. getaddrinfo error: [Name or service not known]\n\niscsiadm: cannot resolve host name ubuntu03c\niscsiadm: Could not perform SendTargets discovery.\n' (nova.root): TRACE:
This error happens when the compute node is unable to resolve the nova-volume server name. You could either add a record for the server if you have a DNS server; or add it into the "/etc/hosts" file of the nova-compute.
ERROR "No route to host"
iscsiadm: cannot make connection to 172.29.200.37: No route to host\niscsiadm: cannot make connection to 172.29.200.37
This error could be caused by several things, but it means only one thing : openiscsi is unable to establish a communication with your nova-volumes server.
The first thing you could do is running a telnet session in order to see if you are able to reach the nova-volume server. From the compute-node, run :
telnet $ip_of_nova_volumes 3260If the session times out, check the server firewall ; or try to ping it. You could also run a tcpdump session which will likely gives you extra information :
tcpdump -nvv -i $iscsi_interface port dest $ip_of_nova_volumesAgain, try to manually run an iSCSI discovery via :
iscsiadm -m discovery -t st -p $ip_of_nova-volumes"Lost connectivity between nova-volumes and node-compute ; how to restore a clean state ?"
Network disconnection can happens, from an "iSCSI view", losing connectivity could be seen as a physical removal of a server's disk. If the instance runs a volume while you loose the network between them, you won't be able to detach the volume. You would encounter several errors. Here is how you could clean this :
First, from the nova-compute, close the active (but stalled) iSCSI session, refer to the volume attached to get the session, and perform the following command :
iscsiadm -m session -r $session_id -uHere is an
iscsi -m sessionoutput :tcp: [1] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-0000000e tcp: [2] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000010 tcp: [3] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000011 tcp: [4] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-0000000a tcp: [5] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000012 tcp: [6] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000007 tcp: [7] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000009 tcp: [9] 172.16.40.244:3260,1 iqn.2010-10.org.openstack:volume-00000014
I would close the session number 9 if I want to free the volume 00000014.
The cloud-controller is actually unaware about the iSCSI session closing, and will keeps the volume state as "in-use":
VOLUME vol-00000014 30 nova in-use (nuage-and-co, nova-cc1, i-0000009a[nova-cn1], \/dev\/sdb) 2011-07-18T12:45:39Z
You now have to inform it that the disk can be used. Nova stores the volumes info into the "volumes" table. You will have to update four fields into the database nova uses (eg. MySQL). First, conect to the database :
mysql -uroot -p$password novaThen, we get some information from the table "volumes" :
mysql> select id,created_at, size, instance_id, status, attach_status, display_name from volumes; +----+---------------------+------+-------------+----------------+---------------+--------------+ | id | created_at | size | instance_id | status | attach_status | display_name | +----+---------------------+------+-------------+----------------+---------------+--------------+ | 1 | 2011-06-08 09:02:49 | 5 | 0 | available | detached | volume1 | | 2 | 2011-06-08 14:04:36 | 5 | 0 | available | detached | NULL | | 3 | 2011-06-08 14:44:55 | 5 | 0 | available | detached | NULL | | 4 | 2011-06-09 09:09:15 | 5 | 0 | error_deleting | detached | NULL | | 5 | 2011-06-10 08:46:33 | 6 | 0 | available | detached | NULL | | 6 | 2011-06-10 09:16:18 | 6 | 0 | available | detached | NULL | | 7 | 2011-06-16 07:45:57 | 10 | 157 | in-use | attached | NULL | | 8 | 2011-06-20 07:51:19 | 10 | 0 | available | detached | NULL | | 9 | 2011-06-21 08:21:38 | 10 | 152 | in-use | attached | NULL | | 10 | 2011-06-22 09:47:42 | 50 | 136 | in-use | attached | NULL | | 11 | 2011-06-30 07:30:48 | 50 | 0 | available | detached | NULL | | 12 | 2011-06-30 11:56:32 | 50 | 0 | available | detached | NULL | | 13 | 2011-06-30 12:12:08 | 50 | 0 | error_deleting | detached | NULL | | 14 | 2011-07-04 12:33:50 | 30 | 155 | in-use | attached | NULL | | 15 | 2011-07-06 15:15:11 | 5 | 0 | error_deleting | detached | NULL | | 16 | 2011-07-07 08:05:44 | 20 | 149 | in-use | attached | NULL | | 20 | 2011-08-30 13:28:24 | 20 | 158 | in-use | attached | NULL | | 17 | 2011-07-13 19:41:13 | 20 | 149 | in-use | attached | NULL | | 18 | 2011-07-18 12:45:39 | 30 | 154 | in-use | attached | NULL | | 19 | 2011-08-22 13:11:06 | 50 | 0 | available | detached | NULL | | 21 | 2011-08-30 15:39:16 | 5 | NULL | error_deleting | detached | NULL | +----+---------------------+------+-------------+----------------+---------------+--------------+ 21 rows in set (0.00 sec)
Once you get the volume id, you will have to run the following sql queries (let's say, my volume 14 as the id number 21 :
mysql> update volumes set mountpoint=NULL where id=21; mysql> update volumes set status="available" where status "error_deleting" where id=21; mysql> update volumes set attach_status="detached" where id=21; mysql> update volumes set instance_id=0 where id=21;Now if you run again
euca-describe-volumesfrom the cloud controller, you should see an available volume now :VOLUME vol-00000014 30 nova available (nuage-and-co, nova-cc1, None, None) 2011-07-18T12:45:39Z
You can now proceed to the volume attachment again!
While Diablo provides the snapshot functionality (using LVM snapshot), were are going to see here how you can backup your EBS-volumes. The way we will do it offers the advantage to make backup that don't size much, in fact, only existing data will be backed up, not the whole volume. So let's suppose we create a 100 gb nova-volume for an instance, while only 4 gigabytes are used ; we will only backup these 4 giga-bytes, here are the tools we are going to use in order to achieve that :
lvm2, in order to directly manipulating the volumes.
kpartx which will help us to discover the partition table created inside the instance.
tar will be used in order to create a minimum-sized backup
sha1sum for calculating our backup checksum, in order to check its consistency
1- Create a snapshot of a used volume
In order to backup our volume, we first need to create a snapshot of it. An LVM snapshot is the exact copy of a logicial volume, which contains datas, at a frozen state. Thus, data corruption is avoided (preventing data manipulation during the process of creating the volume itself). Remember the EBS-like volumes created through a :
$ euca-create-volumeconsists in an LVM's logical volume.Make sure you have enough space (a security is twice the size for a volume snapshot) before creating the snapshot, otherwise, there is a risk the snapshot will become corrupted is not enough space is allocated to it !
So you should be able to list all the volumes by running :
$ lvdisplayDuring our process, we will only work with a volume called "volume-00000001", which, we suppose, is a 10gb volume : but,everything discussed here applies to all volumes, not matter their size. At the end of the section, we will present a script that you could use in order to create scheduled backups.
The script itself exploits what we discuss here. So let's create our snapshot ; this can be achieved while the volume is attached to an instance :
$ lvcreate --size 10G --snapshot --name volume-00000001-snapshot /dev/nova-volumes/volume-00000001We indicate LVM we want a snapshot of an already existing volumes via the "--snapshot" flag, plus the path of an already existing volume (In most cases, the path will be /dev/nova-volumes/$volume_name, the name we want to give to our snapshot, and a size.
This size don't have to be the same as the volume we snapshot, in fact, it's a space that LMV will reserve to our snapshot volume, but, by safety, let's specify the same size (even if we know the whole space is not currently used).
We now have a full snapshot, and it only took few seconds !
Let's check it, by running
$ lvdisplayagain. You should see now your shapshot :--- Logical volume --- LV Name /dev/nova-volumes/volume-00000001 VG Name nova-volumes LV UUID gI8hta-p21U-IW2q-hRN1-nTzN-UC2G-dKbdKr LV Write Access read/write LV snapshot status source of /dev/nova-volumes/volume-00000026-snap [active] LV Status available # open 1 LV Size 15,00 GiB Current LE 3840 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 251:13 --- Logical volume --- LV Name /dev/nova-volumes/volume-00000001-snap VG Name nova-volumes LV UUID HlW3Ep-g5I8-KGQb-IRvi-IRYU-lIKe-wE9zYr LV Write Access read/write LV snapshot status active destination for /dev/nova-volumes/volume-00000026 LV Status available # open 0 LV Size 15,00 GiB Current LE 3840 COW-table size 10,00 GiB COW-table LE 2560 Allocated to snapshot 0,00% Snapshot chunk size 4,00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 251:14
2- Partition table discovery
If we want to exploit that snapshot, and use the tar program accordingly, we first need to mount our partition on the nova-volumes server.
Kpartx is a small utility which performs table partition discoveries, and map it. This is usefull since we will need to use it if we want to see partition creates inside the instance.
Without using the partitions created inside instances, we won' t be able to see it's content, and creating efficient backups. Let's use kpartx (a simple
$ apt-get install kpartxwould do the trick on Debian's flavor distros):$ kpartx -av /dev/nova-volumes/volume-00000001-snapshotIf not any errors is displayed, it means the tools has been able to find it, and map the partition table.
You can easily check that map by running :
$ ls /dev/mapper/nova*You should now see a partition called "nova--volumes-volume--00000001--snapshot1"
If you have created more than one partition on that volumes, you should have accordingly several partitions ( eg :nova--volumes-volume--00000001--snapshot2,nova--volumes-volume--00000001--snapshot3 and so forth).
We can now mount our parition :
$ mount /dev/mapper/nova--volumes-volume--volume--00000001--snapshot1 /mntIf there is not any errors, it means you successfully mounted the partition !
You should now be able to access directly to the datas that were created inside the instance. If you have a message asking for you to specify a partition, or if you are unable to mount it (despite a well-specified filesystem) there could be two causes :
You didn't allocate enough size for the snapshot
kapartx had been unable to discover the partition table.
Try to allocate more space to the snapshot and see if it works.
3- Use tar in order to create archives
Now we have our mounted volume, let's create a backup of it :
$ tar --exclude={"lost+found","some/data/to/exclude"} -czf volume-00000001.tar.gz -C /mnt/ /backup/destinationThis command will create a tar.gz file containing the datas, and datas only, so you ensure you don't waste space by backing up empty sectors !
4- Checksum calculation I
It's always good to have the checksum for your backup files. The checksum is a unique identifier for a file.
When you transfer that same file over the network ; you can run another checksum calculation. Having different checksums means the file is corrupted, so it is an interesting way to make sure your file is has not been corrupted during its transfer.
Let's checksum our file, and save the result to a file :
$sha1sum volume-00000001.tar.gz > volume-00000001.checksumBe aware the sha1sum should be used carefully since the required time for the calculation is proportionate to the file's size.
For files that weight more than ~4-6 gigabytes, and depending on your CPU, it could require a lot of times.
5- After work cleaning
Now we have an efficient and consistent backup ; let's clean a bit :
Umount the volume :
$ umount /mntDelete the partition table :
$ kpartx -dv /dev/nova-volumes/volume-00000001-snapshotRemove the snapshot :
$lvremove -f /dev/nova-volumes/volume-00000001-snapshot
And voila :) You can now repeat these steps for every volume you have.
6- Automate your backups
You will mainly have more and more volumes allocated to your nova-volume service. It might be interesting then to automate things a bit. This script here will assist you on this task. The script does the operations we just did earlier, but also provides mail report and backup running (based on the " backups_retention_days " setting). It is meant to be launched from the server which runs the nova-volumes component.
Here is how a mail report looks like :
Backup Start Time - 07/10 at 01:00:01
Current retention - 7 days
The backup volume is mounted. Proceed...
Removing old backups... : /BACKUPS/EBS-VOL/volume-00000019/volume-00000019_28_09_2011.tar.gz
/BACKUPS/EBS-VOL/volume-00000019 - 0 h 1 m and 21 seconds. Size - 3,5G
The backup volume is mounted. Proceed...
Removing old backups... : /BACKUPS/EBS-VOL/volume-0000001a/volume-0000001a_28_09_2011.tar.gz
/BACKUPS/EBS-VOL/volume-0000001a - 0 h 4 m and 15 seconds. Size - 6,9G
---------------------------------------
Total backups size - 267G - Used space : 35%
Total execution time - 1 h 75 m and 35 seconds
The script also provides the ability to SSH to your instances and run a mysqldump
into them. In order to make this to work, make sure the connection via the nova's
project keys is possible. If you don't want to run the mysqldumps, then just turn
off this functionality by putting enable_mysql_dump=0 into the script
(see all settings at the top of the script)
