Saturday, October 24, 2009
Point in time copies, are they backups?
The simple answer is no, the more complex answer is it depends.
Point in time copies (snapshots) can drastically increase your time to recovery. And can be incredibly useful for data restoration due to an application/operating system/ file system/ user problem.
That being said, really the idea of a true backup is to handle DR and the failure of systems, disks and other problems. Being that your data and copies reside in the same hardware/location it does not protect you against such failures.
Now the reason above I stated is "it depends" is because some vendors are offering the replication of existing point in time copies to a remote system. So the idea is that when it resides on the same system it is not fully useful as a backup media but once it gets transfered/archived and if that archive container the sum total of the original data as well (So a mirror or replication) it can act as a full backup.
Current Problems
There is some possibilities here, If you are simply looking for a point in time to be able to restore to for DR for the short term you can fulfill this with a large archive of remote point in time copies (replicas) but with current vendors these technologies fall flat in two area's
1) Long term storage
A lot of vendors are trying to make improvements in this area but still fall short. While it may be feasible to store weeks or even months worth of daily snapshots is doable with some of todays vendors really keeping a lot of these around for years is non feasible. This storage space is also relativity expensive per GB compared tape and other media. At best it can be used as a "Mid Teir" place to store info to reduce your "race to daylight"
2) Archival, cataloging
No solution that I am aware of (and if you know any different please share!) really handles the cataloging on a file level that is available to some other server side tools. What happens when you have a user that asks "I deleted a very important document from 2 months ago, I don't remember its name exactly but it was financial something or other and was an excel spreadsheet" or "I have not looked at my important financial document in a year but someone changed it in the last year, I want the one that was modified in 2008"
With E discovery tools available to some backup solutions this is easy to do I just search for *financial*.xls? but with block level point in time copies this is not as easy.
Some vendors are making strides (specially if they also do file level shares) and are going in the right direction but are not there yet.
Long term storage
A nice trend I am seeing in industry is the ability to ship point in time copies off to alternative media, this is a great idea. Quite a few vendors are making an effort to be able to do things like use standard NDMP to be able to export the data directly from the SAN to something like a data domain or a VTL or directly to tape. This makes long term storage more feasible and economical.
My take on it
Point in time copies are a great way to prevent against many different types of non storage layer problems, and replicas can even help with that. But in the end without cataloging the usefulness and ability to do file level recovery and E-discovery is non existent. It may be perfectly fine for your industry but in some that is a challenge.
Point in time copies (snapshots) can drastically increase your time to recovery. And can be incredibly useful for data restoration due to an application/operating system/ file system/ user problem.
That being said, really the idea of a true backup is to handle DR and the failure of systems, disks and other problems. Being that your data and copies reside in the same hardware/location it does not protect you against such failures.
Now the reason above I stated is "it depends" is because some vendors are offering the replication of existing point in time copies to a remote system. So the idea is that when it resides on the same system it is not fully useful as a backup media but once it gets transfered/archived and if that archive container the sum total of the original data as well (So a mirror or replication) it can act as a full backup.
Current Problems
There is some possibilities here, If you are simply looking for a point in time to be able to restore to for DR for the short term you can fulfill this with a large archive of remote point in time copies (replicas) but with current vendors these technologies fall flat in two area's
1) Long term storage
A lot of vendors are trying to make improvements in this area but still fall short. While it may be feasible to store weeks or even months worth of daily snapshots is doable with some of todays vendors really keeping a lot of these around for years is non feasible. This storage space is also relativity expensive per GB compared tape and other media. At best it can be used as a "Mid Teir" place to store info to reduce your "race to daylight"
2) Archival, cataloging
No solution that I am aware of (and if you know any different please share!) really handles the cataloging on a file level that is available to some other server side tools. What happens when you have a user that asks "I deleted a very important document from 2 months ago, I don't remember its name exactly but it was financial something or other and was an excel spreadsheet" or "I have not looked at my important financial document in a year but someone changed it in the last year, I want the one that was modified in 2008"
With E discovery tools available to some backup solutions this is easy to do I just search for *financial*.xls? but with block level point in time copies this is not as easy.
Some vendors are making strides (specially if they also do file level shares) and are going in the right direction but are not there yet.
Long term storage
A nice trend I am seeing in industry is the ability to ship point in time copies off to alternative media, this is a great idea. Quite a few vendors are making an effort to be able to do things like use standard NDMP to be able to export the data directly from the SAN to something like a data domain or a VTL or directly to tape. This makes long term storage more feasible and economical.
My take on it
Point in time copies are a great way to prevent against many different types of non storage layer problems, and replicas can even help with that. But in the end without cataloging the usefulness and ability to do file level recovery and E-discovery is non existent. It may be perfectly fine for your industry but in some that is a challenge.
Labels: Backups, Point in time, SAN, Storage
Friday, May 15, 2009
Mass mountain SAN arrays
Mass mountain SAN arrays
We purchased a Mass mountain, as opposed to our normal fair for our new backup to disk product.
The idea was separate low cost hardware with a lot of space, as it was not primary data the performance was not a huge concern. We have run across some issues that put it out of the running for A) primary storage B) This project
First the good:
Mass Mountain uses openE, this allows for a very open and feature rich product. You are able to publish via FC, ISCSI and NAS (all at the same time) along with the ability to bridge other storage devices and publish them out. (For example could connect it to another FC array and publish a volume via ISCSI). Also unlike some others you can put different disk and different RAID all on the same array (For example we wanted a 2 disk SAS raid mirror ISCSI and the other 14 disks raid 50 (with 2 global spares) published NAS in several logical volumes)
As such it is a very very flexible piece of hardware with many options
The bad:
1) No built in way to expand beyond the chassis (Other then using the RAID card to expand the RAID set)
2) Interface non intuitive and often hard to find things
3) Publishing new targets and new volumes via ISCSI restarts the ISCSI service for all volumes (this is a big one!)
4) Max logical volume with replication is 4TB (Deal breaker for our project as it needs a very large single volume)
5) We have had our volumes just “Stop” being published. All servers dropped connection to their ISCSI volumes (this included 2 different RAID containers) The only resolution was to REBOOT the array! No RCA on it.
6) To do MPIO required actually having the NICS on both the SAN and the Servers be in different subnets with the MSISCSI initiator. Which is silly ISCSI is designed to be able for the SAN to be able to control logins and balance between interfaces without having to manually set subnets so they CANT communicate with the other one
All said and done the bads outweigh the goods we have no confidence in the stability and have some deal breaker limitations on size of volumes
As such we have elected to move back to our normally arrays at a significantly higher price for the stability and features
We purchased a Mass mountain, as opposed to our normal fair for our new backup to disk product.
The idea was separate low cost hardware with a lot of space, as it was not primary data the performance was not a huge concern. We have run across some issues that put it out of the running for A) primary storage B) This project
First the good:
Mass Mountain uses openE, this allows for a very open and feature rich product. You are able to publish via FC, ISCSI and NAS (all at the same time) along with the ability to bridge other storage devices and publish them out. (For example could connect it to another FC array and publish a volume via ISCSI). Also unlike some others you can put different disk and different RAID all on the same array (For example we wanted a 2 disk SAS raid mirror ISCSI and the other 14 disks raid 50 (with 2 global spares) published NAS in several logical volumes)
As such it is a very very flexible piece of hardware with many options
The bad:
1) No built in way to expand beyond the chassis (Other then using the RAID card to expand the RAID set)
2) Interface non intuitive and often hard to find things
3) Publishing new targets and new volumes via ISCSI restarts the ISCSI service for all volumes (this is a big one!)
4) Max logical volume with replication is 4TB (Deal breaker for our project as it needs a very large single volume)
5) We have had our volumes just “Stop” being published. All servers dropped connection to their ISCSI volumes (this included 2 different RAID containers) The only resolution was to REBOOT the array! No RCA on it.
6) To do MPIO required actually having the NICS on both the SAN and the Servers be in different subnets with the MSISCSI initiator. Which is silly ISCSI is designed to be able for the SAN to be able to control logins and balance between interfaces without having to manually set subnets so they CANT communicate with the other one
All said and done the bads outweigh the goods we have no confidence in the stability and have some deal breaker limitations on size of volumes
As such we have elected to move back to our normally arrays at a significantly higher price for the stability and features
Labels: FC, ISCSI, MassMountain, NAS, SAN
Friday, March 27, 2009
Updating the CEMI on equallogic PS5000 series
Here is a rather interesting problem that I ran across the last 2 weeks in the process of replacing a control module
Note most of the steps provided here it is recommended that you contact your storage service provider, some of these are clearly not recommended by equallogic
On to the problem…
After swapping control module the array pages out that the primary and the secondary control module CEMI version is different. In my case the CEMI of the replaced control module is 6.08 when it should on a 6.11 with the PS5000xv at this point in time
1) Connect to the control module you want to update with the serial cable
2) Log into bash shell with the command “su exec /bin/bash”
3) You can check the CEMI version with the command “cemi_update –v” (sometimes it will show up as all 0000 this is not unexpected I will cover another way to check later)
4) Check that the file cemi611.bin exists in the folder /pss/primary/
5) Run the command “cemi_update –f /pss/primary/cemi0611.bin”
The update can take awhile and it may take even longer for it to show up (30 + min) … the second way to check the version is at the bash prompt type in “ecli” it will bring you to a new prompt. Then type the command “cmv” that will show you a bunch of info including the CEMI version
Note that the ecli screen has a bunch of environmental system information and settings.
Now in some cases (like mine) cmv did not show the actual version, it was recommended to me to reseat the control module to verify the update happened. (It did)
Also note that this should not be performed on the primary controller as there is possible downtime associated
Note most of the steps provided here it is recommended that you contact your storage service provider, some of these are clearly not recommended by equallogic
On to the problem…
After swapping control module the array pages out that the primary and the secondary control module CEMI version is different. In my case the CEMI of the replaced control module is 6.08 when it should on a 6.11 with the PS5000xv at this point in time
1) Connect to the control module you want to update with the serial cable
2) Log into bash shell with the command “su exec /bin/bash”
3) You can check the CEMI version with the command “cemi_update –v” (sometimes it will show up as all 0000 this is not unexpected I will cover another way to check later)
4) Check that the file cemi611.bin exists in the folder /pss/primary/
5) Run the command “cemi_update –f /pss/primary/cemi0611.bin”
The update can take awhile and it may take even longer for it to show up (30 + min) … the second way to check the version is at the bash prompt type in “ecli” it will bring you to a new prompt. Then type the command “cmv” that will show you a bunch of info including the CEMI version
Note that the ecli screen has a bunch of environmental system information and settings.
Now in some cases (like mine) cmv did not show the actual version, it was recommended to me to reseat the control module to verify the update happened. (It did)
Also note that this should not be performed on the primary controller as there is possible downtime associated
Labels: CEMI, equallogic, PS5000, SAN
Subscribe to Posts [Atom]