For the release of both Mac OS X Tiger (10.4 – 2005) and Max OS X Leopard (10.5 – 2007), Apple had various mocking campaigns and posters for the preceding conferences with slogans along the lines of:

Redmond, start your photocopiers

This was a very public and very open jibe from Apple regarding Microsoft’s reputation for simply copying features from Mac OS X. Now, I don’t want to really get into the “you’re a fanboy – no, you’re a fanboy!” style argument, but I do want to suggest that given the recent debacle that’s started to surface over the abysmal performance of the Windows 7 backup process, Microsoft appears to be cutting their noses off to spite their faces.

Back on 6 March 2009, I covered just how amazing Time Machine was as an OS-integrated backup product. I never said it was something that would replace enterprise products like NetWorker, but I did say:

This, quite honestly, is the epitome of simplicity. Going beyond standard backup and recovery operations, Time Machine is also an excellent disaster recovery tool – if you have serious enough issues that you need to rebuild your machine, the Mac OS X installer actually has the option of doing a rebuild and recovery from Time Machine backups.

To be blunt – as a backup utility for end users, Time Machine is an ace in the hole, and one of the most underrated features of Mac OS X.

Sure, Time Machine doesn’t do everything that every user wants it to do – but then again, no product ever will. Yet I’ve backed up a significant number of TB (as far as desktops go) using Time Machine, and recently I was highly pleased to be able to recover 18 months of my fathers’ hard work with no effort at all. This was from a machine where I’d setup Time Machine and had not had a chance to visit since – nor check remotely, since my parents don’t use the internet.

So frankly, on behalf of Windows users, I’m somewhat horrified at the experiences being felt with Microsoft’s Windows 7 backup utility – and their use case scenarios!

As documented over at The Register, “Windows 7 Backup Gets Users’ Backs Up”, there’s a litany of issues being reported:

Jon Hell posted on April 23 that he is backing up 900GB of data on a quad core PC with 7GB of RAM; “After twenty four hours Windows Backup had managed to complete 18 per cent of the backup, but after forty eight hours, it had got even slower, and had only reached 23 per cent of the full backup.”

And:

John Dougrez-Lewis was the first poster, and wrote that he could use file copy to move 250GB of file data to an external eSATA drive in an hour at a speed of 72MB/sec. When he did the same job using Windows 7 RTM Backup it took 14 hours, roughly 5MB/sec – more than 14 times slower.

If these were isolated experiences it could be understood – after all, no product will work perfectly for every single person.

The actual Microsoft forum regarding the issues is directly available via this link. We also see an article from Microsoft, Backing up large data set on Windows 7:

Windows Backup is optimized to help home users protect their important data on their PCs and this is typically expected to be 200GB of data on average. On a PC that contains significantly larger data size, Windows Backup’s performance may degrade. If you need to back up more than 400GB of data, we recommend that you backup your PC using a system image.

Sorry to say, but this “meh” attitude towards backup turns my stomach. If this were an article published a decade ago about an OS-included backup utility it might be understandable – after all, a decade ago, 400GB of data was a big amount!

The article goes on to provide instructions for setting up a scheduled system image. Sure, the average techo will look at the instructions provided and punch through them in a couple of minutes at most, but with instructions like the following, you’re guaranteed to (a) turn most average users off and (b) definitely provide a terrible user experience:

If you have a separate data drive, you will need to create a task in Task Scheduler to create the system image:

a.      Open an elevated command prompt

b.      Type the following command:

SCHTASKS /Create /SC <Frequency> /TN <TaskName> /RL HIGHEST /ST <StartTime> /TR “WBADMIN START Backup –backupTarget:<target> -include:<source> -quiet”

This goes to the heart of why Time Machine is so successful – Apple recognised that the only way to get users to backup is to make it painless and easy. Microsoft’s approach to end-user backup seems to be diametrically opposed to that of Apple – and as a result of it, I know which backup mechanism will save more consumer data, even given the hugely different market shares of the platforms.

When it comes to backup, Microsoft would do well to “start their photocopiers”.

 

The classic NetWorker install will see:

  • A bunch of clients
  • Optional storage nodes and/or dedicated storage nodes
  • The NetWorker server
  • The NetWorker Management Console server running on the NetWorker server

Architecturally, there’s no reason why you have to have the NetWorker Management Console server running on the backup server itself. Both logically and architecturally, there are good reasons why you would choose to keep these separate. Let’s start by using a diagram to show how the alternate architecture looks:

Divorcing NetWorker Management Console Server from Backup Server

So, what are the advantages of this sort of layout? There’s three distinct advantages:

  • Feature access – in my experience the vast majority of backup administrators are conservative in their approach to the technology in use. This means that there’s a slow-ramping process for adoption of new backup server software. While some users will hop on the bandwagon straight away, others will wait for a while. The momentum eventually builds up, but it takes a while to get there. In the meantime though, we periodically encounter situations where the features in the latest version of NMC are highly desirable. For instance, the unified monitoring provided in the version of NMC that comes with NetWorker 7.6 should appeal to just about every NetWorker administrator out there. If the NMC server and the NetWorker server are one and the same machine, it makes rolling out a new version of NMC while keeping the old version of NetWorker practically impossible. On the other hand, if the NMC server and the NetWorker server aren’t the same machine, it’s trivial to upgrade a single client to the latest version of NetWorker and NMC.
  • Performance – in small environments, the footprint of the NMC server creates negligible additional load on the backup server. As the number of clients and simultaneously active savesets ramps up though, the load of the NMC server – particularly with multiple accessing consoles – the impact of running the NetWorker Management Console server on the backup server can be observed. By keeping these hosts separate, the problem does not happen.
  • Protection – the NMC server has become considerably more stable over its lifetime, but like all software, there are no guarantees that it is crash proof. If the NMC server isn’t running on the same host as the backup server, then it gives you the advantage of being able to reboot the NMC server should there be an issue with monitoring, without impacting the actual backup server itself. In actual fact, keeping systems separate that don’t need to be together gives you better options for fault handling, upgrades and scheduled maintenance.

Assuming you want to run the NMC server as a separate host to the NetWorker server, it’s really quite easy:

  • Using either nsradmin or the existing NMC install on the backup server, modify NetWorker’s Administrator user group to include administrators from the NMC server.
  • Install the NMC server and NetWorker client software on the intended host. (If on Unix, I always recommend also installing the NetWorker man pages. You never know when you’ll need them.) Be sure to allow NetWorker to setup the NMC backup instance if you want your database backed up and aren’t sure how to configure this manually.
  • Shutdown NMC on your backup server and configure it to not automatically start up. If necessary you can start it later to retrieve historical reports – otherwise you can leave it there installed, but not running, to avoid confusion.
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha