This post will detail the steps to go through to allow you to create storage level snapshots using DELL EqualLogic ASM/LE on Linux SLES 11 SP2, and then move the data off onto other storage arrays. – This is handy if your budget doesnt have room to use the nice features of EqualLogic SyncRep,etc. to another remote EqualLogic group.
The main benefit for me of using this technique, is that once DB2 has actually completed its daily application level backups, I dont need to then clog up I/O and CPU time on the server whilst I then use a client based backup for example.
The DB2 server backup filesystem is stored on DELL EqualLogic, meaning that its possible for me to create storage level snapshots using ASM/LE.
For my purposes I created a physically separate SLES 11 SP2 Linux server which I also installed the HIT tools and configured ASM/LE on this as well as the DB2 servers themselves. Ideally, I would have the location of the ASM metadata served from a shared filesystem somewhere, but that is out of the scope of this post.
So, the DB2 backup completes and then I’m left with a filesystem containing the DB2 dumps,i.e.: “DBNAME.0.instanceowner.DBPART000.20130209210003.001“, but now have to decide: “do I now waste more server time getting it to tape/another disk,etc??”
To get around this I chose to use storage level snapshots, starting off on the DB2 server.
Prior to this I have setup a snapshot reserve of 100% on the original LUN on the EqualLogic and configured a storage admin user within the EQL Group admin interface. Again, I am assuming that the reader has some familiarity with configuring their EqualLogic environment.
asmcli create smart-copy –source /db2_db1_backups
this will create a quiesced point in time picture of this filesystem. If you have multiple database instances on one server or spread across multiple servers, the same process can be repeated, as the ASM process maintains a list of its own with unique object ids, meaning you can mount separate system snapshots on one remote ‘restoration’ server.
Next, change directory to the default location for the smart-copy information
then create a tar of the smart-copy list ( do this for each DB2 server you want to cover)
tar cvf asm-le-DB2server1.local.tar asm-le-DB2server1.local
then scp the tar to the Linux backup server
“scp asm-le-DB2server1.local.tar [email protected]:/var/lib/equallogic/asm/smart-copies/”
Next, ssh onto the Linux backup server, and change directory to “/var/lib/equallogic/asm/smart-copies“, and untar each tar file.
When you next run “asmcli list smart-copy” on the Linux backup server you should see a list of the snapshots that you took on the original DB2 server and the object ids for each snapshot
Create a mountpoint for the snapshot to mount against
It will now be possible to run:
asmcli mount smart-copy –object <object-id> –destination /snapshots_db2server1/
You will now see a verbose message detailing if the mounting of the snapshot was successful.
If you now change directory to /snapshots_db2server1 you should see the original backup directory structure sitting underneath there.
Its now up to you to choose how and where you want to copy the data contained in that snapshot.
For my part, I had a ‘cheaper-than-EqualLogic’ iSCSI storage SAN (which I mounted under ‘/DB2backup_drive‘ ) which I then rsync’d from inside the snapshot.
“rsync -avz –delete /snapshots_db2server1/db2_db1_backups/ /DB2backup_drive/db2_backups/db2_db1_backups/ &”
The other good thing about using the snapshot with rsync, is that if you are using full archive logging and performing incremental backups within DB2, then every time you run the snapshot, you can get away with only having to sync over the incrementals, until next full backup time.
This will now allow me to continue on using the original DB2 server without any additional CPU overhead, whilst I give myself an atomic copy of the DB2 backup directory and its dump files on a completely separate environment.
I can then choose at a later date, (if I wanted to) to run this data to a tape for example. This process (with modifications on the snapshots to include the DB2 data and log directories) also makes it possible to create a complete and reduced expense ‘like-for-like’ scripted test environment for DB2, which I will link back to in the future.
Once you are done with the snapshots you can of course unmount them using asmcli not the traditional Linux unmount command.
You can find out which object id to specify, by running ‘df’ and the object id is included as part of the device name created for the mount process by asmcli. Like so..
So the object id to pass to asmcli is c-a20a51-a646709dd-a94bebfe0e54d2a6, i.e.:
asmcli unmount smart-copy –object c-a20a51-a646709dd-a94bebfe0e54d2a6
Hope you found this article helpful!
(c) Matt Palmer 19-Feb-2013