veeam | Steve Dolphin

78H6_6C88C7C2-0E45-4253-A035-B6CA193A5FD5_large

Enlarge 1 Comment

NAS comparison: iomega and netgear

As you will know, I’ve had no end of problems with iomega NAS boxes (and customer support for that matter), and so with a recent purchase decided to test the market again and purchase a different product.

Back in the day we had some Netgear ReadyNas boxes, little desktop units offering 2-3TB of network storage which was ideal for backups. The ReadyNas boxes weren’t special in any way, the interface was decidedly average and the software had a few quirks, but they did have one brilliant feature – they hardly ever stopped working.

So, I decided to give them a go again and have since done a direct comparison between the previously-complained-about iomega units and the newly-purchased netgear ones. There are a couple of differences you should know before you worry about the performance though: 1) the netgears are considerably more expensive; 2) the netgears come with a much better warranty.
Continue Reading →

Enlarge 0 Comment

Quick: Why not to buy the iomega ix12-300r either!

In a previous blog post I explained that our iomega ix4-200r was a generally faulty product with little or no hope of ever making it into my good books, mainly because of the (deliberate) limitations on iSCSI LUN sizes.

After feeding this information back to the suppliers who recommended the product they gave a response which was something like “oh, yes, well, those are the small units, they’re not too good, try the larger unit instead: the ix12″.

And so we did, we bought a few ix12-300r units and configured them up appropriately, the good news is they don’t have a restriction on iSCSI LUNs that I’m bothered about – it might be set at 16TB but I’m okay with that. The bad news is, the product itself is just as unreliable and realistically can’t be used for anything sensible. We had a fault initially logged on the 13th October and as I write this on the 5th December it’s still not resolved fully.
Continue Reading →

Quick: Why not to buy the iomega ix4-200r for veeam backups

In previous blog posts (Using veeam to backup the new virtual infrastructure to Iomega NAS boxes and Backup Strategies with Virtual Machines in VMware using Veeam) I mention my purchases of the iomega ix4-200r, generally I haven’t been impressed with them because they’ve been a little unreliable.

Looking at use around the net I decided that the best way to have a target for my veeam backups would be the iSCSI initiator from Windows straight onto the device, so I should provision a LUN, add it to Windows and write to it.

I tried and failed, after about a week of to’ing and fro’ing with veeam, vmware and iomega support I got to the bottom of the issue: these nas boxes are software locked to provide LUNs that are <= 2TB in size* – bearing in mind my 8 file servers each serve up anywhere between 500GB and 1TB worth of data this means that my first backup file from veeam is always going be over 2TB, making the device pretty much worthless in my environment.

*I’ve been assured that a LUN that’s exactly 2TB will work, although I can’t actually get that working in my test lab having tried it on two separate devices.

Using the Dell EQL MEM Module to simplify my backups (also, thanks again, veeam!)

Many posts cover the installation and performance benefits that come from using the Dell Multipathing Extension Module (MEM) on EqualLogic arrays (check the spoonapedia.com one), but the big difference for me was a bit of a pleasant side-effect in terms of handling backups! I’ve covered off this strategy from a high level in my previous blog post, Backup Strategies with Virtual Machines in VMware using Veeam, but I wanted to explain in a little bit of detail how I actually got there: it was down to the MEM!

Before – accessing data from within the OS

Because the file servers I’ve been working on access a lot of data (8TB worth), the original setup involved using the EqualLogic Host Integration Tools (HIT kit) from within the file server OS to access LUNs on the EQL array – this provided valuable multipath access and proved to be a very successful way of handling access to the data. The problem was that is complicated backups quite significantly, I could use veeam to backup the OSs (and I did), but I had no way of backing up the actual file data.

With various bad experiences from using market-leading backup software such as BackupExec in the past I wasn’t in a rush to go out and spend money on a software solution to handle all this file data, so I resorted to a very low-tech solution: I bought a nas box and did a nightly robocopy.

This was simple, but it was awful: the backups didn’t finish in time (they’re being taken over a 100mbit LES), they never caught up with themselves. It was a waste of time and it basically meant no backups were worth having.

After – install the MEM and let ESXi deal with it

But then the MEM came out, and essentially claimed to offer the same (if not better) performance via ESXi – no messing around with the HIT kit any more, and more importantly, a chance to re-evaluate my first decision about not using .vmdks… I changed my mind.

The first time round I did thick LUN straight into Windows, formatted as NTFS, simple. This time I re-evaluated and did a thick LUN on the EQL and then allocated thin disks in ESXi and mounted them to the file servers… This gives me greater flexibility if a disk gets close to its limits but it also now means that the extra .vmdks are picked up by veeam allowing me to replicate my previously successful backup strategy.

In summary…

Veeam now handles the file data as incremental .vmdks which means it only transfers the changes in the .vmdk files – the entire series of backups finishes over the 100mb LES in about 12 hours (which, bearing in mind I run it once a week at the weekend is ideal); the previous robocopy never finished in that amount of time: the size of the data transferred is obviously the same, but because robocopy iterated through every single file and folder for a comparison it took much longer whereas now veeam just… does it, and it was a product that I already had so didn’t require any extra spend (not to mention the money that could now be saved on not upgrading the LES to 1GB purely for the purposes of backup).

Next?

Now being quite satisfied with this setup I’m going to investigate the series of advice from ErikZandboer on optimising his ix2-200 backup speeds, specifically the post that looks at jumbo frames to target storage.

Backup Strategies with Virtual Machines in VMware using Veeam

A recent tweet from @win2ksrv and then retweeted by @veeam reminded me that I was going to write about the most recent backup strategy that I’d put in place using Dell EqualLogic SANs, VMware and of course, veeam, it went like this:

What is everyone’s Veeam backup strategy? What do you backup to & how do you get it offsite? Where do you place Veeam itself?

The basic setup looks like this:

The Production site has a Dell EqualLogic array and a local NAS box (that’s the black thing), the backup site which is connected via a 25mbps internet-based VPN simply has a larger NAS box (it deals with multiple sites). VMware has been used to create all the file server disks (they are .vmdks) and veeam is installed in another virtual machine using appliance mode to access the SAN.

There are essentially two main risks that we want to mitigate against here:

Accidental deletion / corruption of files
Complete site wipeout (i.e. full blown disaster)

Continue Reading →

Enlarge 0 Comment

New office success!

A fairly unique opportunity arose for me towards the end of 2010: I was able to design, purchase components for, and then oversee the implementation of a new office infrastructure. This was due to a new physical build, and based on the success of the previous SAN and Infrastrucure project, I was essentially given full control over all aspects of the IT infrastructure.

It was an extensive piece of work and covered about six months of my life before finally going live at the end of November 2010, it involved visits to the site before building works were completed; setup of an entire dedicated test lab; and various correspondances thrasing out the business requirements for the new build.

The actual move-and-go-live happened over a weekend, the staff downed tools on Friday, had their PCs moved over the weekend and were able to log on and start work again Monday morning, a huge achievement bearing in mind that the entire system had changed: everything from the cables to the printers to the back end storage was now completely different.
Continue Reading →

Backup diagram using veeam and iomega nas

Enlarge 0 Comment

Using veeam to backup the new virtual infrastructure to Iomega NAS boxes

I think it’s safe to say that veeam have been fairly “market disruptive” with their backup software, they’ve joined in on the virtualisation game at the right time and they’re offering a simple product that does exactly what people want: backing up vmware virtual machines.

To major things have lead to this success in my opinion, firstly it’s not very expensive, it works out to be, give or take, £500 per physical socket. So if you’ve got two 2xCPU servers like R710s and you buy some cheap storage you can get your virtual environment backed up from anywhere between £3,000 and £5,000 – which isn’t really that unreasonable.

A virtualisation company based in Bristol, Computerworld, recommended the Iomega StorCentre Pro range as being suitable dumps for this sort of backup, and I settled on a simple 1U device offering just over 5TB of data when using the built in raid (8TB raw), it cost just under £2,000. Update: don’t buy these if you have large backup files! It was so cheap that I decided to buy two, and then use a staged backup system which would handle our file servers as well as the veeam server backups, it looks a little like this:

Firstly the veeam server queries the vCentre server (vSphere in the diagram) to get a list of virtual machines
veeam then drills down into the SAN to access the data directly for a speedy backup
this data is then written to a NAS box which is plugged into the same switch, for speed
Periodically data is then taken to the off-site backup location. In my diagram the two are linked by 100mb LES, but this could be over a WAN link or even a different room in the same building.
The data is written to a NAS box in the off-site location too
The Windows machine in the off-site location then performs backups to tapes using the local copy of data, rather than the live copy

Staged backups aren’t new by any means, but they’re still a handy way of ensuring that if your backup to tape DOES take more than a few hours overnight that you don’t affect your production systems.

I haven’t actually implemented the tape drive portion of this diagram yet (6) but it’s going to be ordered pretty soon.

All in all with this system now in place for just over a week my virtual machine backups only take 2 hours to backup 22 machines, I can definitely live with that. I’ve also added a spare ESXi install to the veeam console so that I can test restoring individual machines to it, it seems to work pretty well and the user interface is intuitive enough that anyone could do it in an emergency.

In this particular instance I haven’t yet implemented a full business continuity plan, but when I do I know that veeam will come into play again due to its ability to replicate virtual machines from one ESX(i) host to another and perform failovers when asked. All in all I’m very happy with the purchase!