Please see my other blog for Oracle EBusiness Suite Posts - EBMentors

Search This Blog

Note: All the posts are based on practical approach avoiding lengthy theory. All have been tested on some development servers. Please don’t test any post on production servers until you are sure.

Sunday, November 17, 2013

Exadata: Taking System Backup using LVM Snapshots


Recently, Oracle began shipping Exadata with the Linux LVM configured for managing file system storage on the database servers. Logical volume managers provide an abstraction layer for physical diskpartitions similar to the way ASM does for its underlying physical storage devices. 

LVM snapshots eliminate many of the typical challenges we face with simple backups using the tar command or third-party backup products. For example, depending on the amount of data in the backup set, file system backups can take quite a while to complete. These backups are not consistent to a point in time, meaning that if you must restore a file system from backup, the data in your files will represent various points in time from the beginning of the backup process to its end. Applications that continue to run during the backup cycle can hold locks on files, causing them to be skipped (not backed up). And once again, open applications will inevitably
make changes to data during the backup cycle. Even if you are able to back up these open files, you have no way of knowing if they are in any usable state unless the application is shut down before the backup is taken.


A snapshot volume is a special type of volume that presents all the data that was in the volume at the time the snapshot was created. You can create a temporary LVM partition if you have enough free space in the volume group.

In my test environment , I had not space space for the volume so I had to create the new volume for the example purpose. 

[root@exadb ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sda2
VG Name VolGroup00
PV Size 49.90 GB / not usable 25.37 MB
Allocatable yes (but full)
PE Size (KByte) 32768
Total PE 1596
Free PE 0
Allocated PE 1596
PV UUID 6Fm5nC-4GGM-w8Ec-pqDQ-t3tn-usjP-RgnhPo

[root@exadb ~]# vgdisplay
--- Volume group ---
VG Name VolGroup00
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 49.88 GB
PE Size 32.00 MB
Total PE 1596
Alloc PE / Size 1596 / 49.88 GB
Free PE / Size 0 / 0
VG UUID 6o0Qaa-sWkO-Fzpc-05Nx-cY91-IID0-zb7Ous


I added a new drive (50G) to my server and created the partition (sdb1) for it using fdisk
then verified the physical volume.

[root@exadb ~]# pvdisplay /dev/sdb1
"/dev/sdb1" is a new physical volume of "50.00 GB"
--- NEW Physical volume ---
PV Name /dev/sdb1
VG Name
PV Size 50.00 GB
Allocatable NO
PE Size (KByte) 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID SUDSzj-2qI1-7apF-a916-fG0y-mfeE-djrJhh



Having created the physical volumes the next step is to create the volume group. 
[root@exadb ~]# vgcreate db_sysbkp /dev/sdb1 -v 
    Wiping cache of LVM-capable devices
    Wiping cache of LVM-capable devices
    Adding physical volume '/dev/sdb1' to volume group 'db_sysbkp'
    Archiving volume group "db_sysbkp" metadata (seqno 0).
    Creating volume group backup "/etc/lvm/backup/db_sysbkp" (seqno 1).
  Volume group "db_sysbkp" successfully created
-- verify the volume group has been created

See the attributes of newly created volume group
[root@exadb ~]# vgdisplay db_sysbkp
--- Volume group ---
VG Name db_sysbkp
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 50.00 GB
PE Size 4.00 MB
Total PE 12799
Alloc PE / Size 0 / 0
Free PE / Size 12799 / 50.00 GB
VG UUID OwxfW5-XEY2-BJuP-ylyI-E2AR-d1aG-S3DIdC

Up to this point you have just got the new volume group which may be in your case already available. Below is the process to use the LVM snapshot once you have sufficient space in any volume group.

Process to take System Backup
1- Create destination (SAN/NAS/NFS) for the final copy of backups. You can create the logical volume in a volume group for this purpose. Determine the volume group and create the logical volume. In my case I already had the volume group "VGdb" with 50GB space. I used the command lvcreate  to create logical volume in it.

[root@exadb ~]# lvcreate -L 25G -n /dev/VGdb/dbbkp
   Logical volume "dbbkp" created

-L option allows specification of the logical volume size in Megabytes, Terabytes, Petabytes or Exabytes
-n option, which is used to specify a name for the logical volume. If this is not specified, the logical volume name defaults to the next default logical volume number.

2- After crating logical volume verify the VGdb volume group allocations
[root@exadb ~]# vgdisplay VGdb
--- Volume group ---
VG Name VGdb
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 50.00 GB
PE Size 4.00 MB
Total PE 12799
Alloc PE / Size 6400 / 25.00 GB
Free PE / Size 6399 / 25.00 GB

VG UUID OwxfW5-XEY2-BJuP-ylyI-E2AR-d1aG-S3DIdC


3- Create a file system, now we can create a new file system on the dbbkp partition created in step 1.
[root@exadb sbin]# mkfs.ext3 -m 0 -b 4096 /dev/VGdb/dbbkp
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3276800 inodes, 6553600 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
200 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 35 mounts or

180 days, whichever comes first.  Use tune2fs -c or -i to override.

-b block-size: Specifies the size of blocks in bytes. Valid block size vales are 1024, 2048 and 4096 bytes per block.
-m reserved-blocks-percentage: Specifies the percentage of the file system blocks reserved for the super-user.

4- Create the target directory and mount the new file system where backup will be placed.
[root@exadb dev]# mkdir /mnt/databasebkp
[root@exadb dev]# mount /dev/VGdb/dbbkp /mnt/databasebkp
[root@exadb dev]# df -k /mnt/databasebkp
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VGdb-dbbkp
                      25803068    176200  25626868   1% /mnt/databasebkp
[root@exadb dev]# 

[root@exadb dev]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                       44G   13G   29G  30% /
/dev/sda1              99M   23M   71M  25% /boot
tmpfs                 1.5G  966M  505M  66% /dev/shm
VOBXSHARED            368G  259G  109G  71% /media/sf_VOBXSHARED
/dev/sr0               94K   94K     0 100% /media/20131031_1914
/dev/mapper/VGdb-dbbkp
                       25G  173M   25G   1% /mnt/databasebkp

At this point , now you have the place (/mnt/databasebkp) to stage your backup images. 

5- Know your logical volumes for which, you want to take the backup. In my case I've the volume group "db_sysbkp" (50G) with logical volume "sysbkp" (25G) already . If you don't have logical volume for a volume group you could create like below.
[root@exadb ~]# lvcreate -L 25G -n /dev/db_sysbkp/sysbkp
  Logical volume "sysbkp" created

after crating logical volume you could verify the volume group "db_sysbkp" attributes
[root@exadb ~]# vgdisplay db_sysbkp
--- Volume group ---
  VG Name               db_sysbkp
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               50.00 GB
  PE Size               4.00 MB
  Total PE              12799
  Alloc PE / Size       6400 / 25.00 GB
  Free  PE / Size       6399 / 25.00 GB
  VG UUID               OwxfW5-XEY2-BJuP-ylyI-E2AR-d1aG-S3DIdC

6- Once you know the logical volumes to be backed up (eg; sysbkp) , you can create LVM snapshot.
[root@exadb dev]# lvcreate -L5G -s -n syssnap1 /dev/db_sysbkp/sysbkp
  Logical volume "syssnap1" created


-L parameter determines the size of the snapshot volume

When the datablocks are modified or deleted after the snapshot is created , the original copy
of the block is written to the snapshot. It is important to size the snapshot sufficiently to store 
an original copy of all chaneged blocks. If snapshot runs out of space , it will be deactivated.

From the operating system point of view snapshot will be a block device containing the information from /dev/db_sysbkp/syssnap1 from the moment the snapshot was taken.
[root@exadb dev]# ls d*
dm-0  dm-1  dsp  dvd  dvd-sr0
db_sysbkp:
sysbkp  syssnap1
disk:
by-id  by-label  by-path  by-uuid
[root@exadb dev]# 

See the LVM snapshot info
[root@exadb dev]# lvdisplay /dev/db_sysbkp/syssnap1
  --- Logical volume ---
  LV Name                /dev/db_sysbkp/syssnap1
  VG Name                db_sysbkp
  LV UUID                rOXrZh-OH6B-Cviy-QuNb-4UTJ-mPxQ-1ddC0J
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/db_sysbkp/sysbkp
  LV Status              available
  # open                 0
  LV Size                25.00 GB
  Current LE             6400
  COW-table size         5.00 GB
  COW-table LE           1280
  Allocated to snapshot  0.00% 
  Snapshot chunk size    4.00 KB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3

7- Mount the snapshot as you would any other file system. First we will create a directory to use as mount point for our snapshot. Then we will mount it.
[root@exadb dev]# mkdir /mnt/snap
[root@exadb ~]# mount /dev/db_sysbkp/syssnap1 /mnt/snap
[root@exadb dev]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
VOBXSHARED on /media/sf_VOBXSHARED type vboxsf (gid=500,rw)
/dev/sr0 on /media/20131031_1914 type iso9660 (ro,nosuid,nodev,uid=0)
/dev/mapper/db_sysbkp-sysbkp on /mnt/sysbkp type ext3 (rw)
/dev/mapper/db_sysbkp-syssnap1 on /mnt/snap type ext3 (rw)
[root@exadb dev]# 

[root@exadb /]# lvscan
  ACTIVE   Original '/dev/db_sysbkp/sysbkp' [25.00 GB] inherit
  ACTIVE   Snapshot '/dev/db_sysbkp/syssnap1' [5.00 GB] inherit
  ACTIVE            '/dev/VolGroup00/LogVol00' [45.03 GB] inherit
  ACTIVE            '/dev/VolGroup00/LogVol01' [4.84 GB] inherit

Once the snapshot is mounted , we can browse just like any other filesystem. They look and feel

just like the original file system, with one exception that it will not show the files and contents created/modified after the snapshot creation. 


8- Test and verify. I created the a text file in the volume (Original) for the test purpose before the snapshot creation with two lines like below. (You should do it just before step 6 )
[root@exadb sysbkp]# echo "First Line" >> /mnt/sysbkp/f1.txt
[root@exadb sysbkp]# echo "Second Line" >> /mnt/sysbkp/f1.txt
[root@exadb sysbkp]# cat /mnt/sysbkp/f1.txt
First Line
Second Line

After creating and mounting the LVM snapshot (Step 6,7)  I modified the contents of the file like below
[root@exadb sysbkp]# echo "Third Line - added" >> /mnt/sysbkp/f1.txt
[root@exadb sysbkp]# cat /mnt/sysbkp/f1.txt
First Line
Second Line
Third Line - added

You can see that "Third Line - added" appears in the file (Observe this file is on original volume)

Now check the same file on the LVM snapshot volume

[root@exadb mnt]# cd snap
[root@exadb snap]# ls
f1.txt  lost+found
[root@exadb snap]# cat f1.txt
First Line
Second Line

You don't see the "Third Line - added"  (Observe this the snapshot volume)

9- After your testing is done and you are comfortable with the results, finally take the backup using tar command.

[root@exadb snap]# cd /mnt/snap
[root@exadb snap]# tar -pjcvf /mnt/sysbkp/exadb_system_backup.tar.bz2 * /boot --exclude /mnt/sysbkp/exadb_system_backup.tar.bz2 >/tmp/exadata_system_backup.stdout 2>/tmp/exadata_system_backup.stderr

Note that /boot file system does not use the LVM for storage. This file system must be backed up using the tar command. That is not the problem, because /boot file system is fairly small and static so I'm not concerned with these files being modified, locked or open during the backup cycle.

10- Unmount the filesystem for snapshot and remove it.

[root@exadb ~]# umount /mnt/snap
[root@exadb ~]# lvremove /dev/db_sysbkp/syssnap1
Do you really want to remove active logical volume syssnap1? [y/n]: y
  Logical volume "syssnap1" successfully removed


Note: I've used the example to take the backup for the non-Oracle volume but you can take the Oracle related volumes int he same way. 

2 comments:

jonathan said...
This comment has been removed by the author.
jonathan said...

This blog is full of knowledge. I found valuable information on how to take backup using LVM Snapshot. Thanks for sharing