If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
server-free backup, is it useful?
When SAN concept started to gain some market exposure circa 1999 (to me at
least), there was much talk about one of the real benefits, namely server-free backup. The LUN(s) on a production system would be directly backed up to tape over fibre channel, not passing any host. To this day, I have never implemented it, or talked to anyone face to face who has. Specific implementation issues aside, one of my own theories is the the concept isn't that useful, for two reasons: 1. Pulling the raw block structure from the production LUN(s) is a sequential read-only process. This it would severely impact the generally random read/write process from the production system. Head contention would ensue with two so different usage patterns. 2. We can't do a selective restore on the file level, it's the entire LUN or nothing. Another approach is to create snapshot LUNs within the storage subsystem, mounting the snapshot on a backup host and the copying the LUN to a backup medium (disk or tape). This makes much more sense to me. Although head contention is still a risk, it might be possible to throttle the backup process. In a server-free environment, the major point is the speed of the backup. If you throttle it, well what's the point?. Another major benefit is the ability to immediately recover if the production LUN should become corrupted. It doesn't matter how fast a server-free restore is, with a snapshot waiting to be restored I'm already done. Such implementations seem to be far more common. I've even done a few myself. Also, since I mount the snapshot LUN on another (or same) host I can tinker with file level restores to my heart's content. Again, these are just my own theories. I've discussed them with collegues, but noone can say whether I'm right or wrong really. I'd appreciate any comments. /charles |
#2
|
|||
|
|||
"Charles Morrall" wrote in message
... When SAN concept started to gain some market exposure circa 1999 (to me at least), there was much talk about one of the real benefits, namely server-free backup. The LUN(s) on a production system would be directly backed up to tape over fibre channel, not passing any host. To this day, I have never implemented it, or talked to anyone face to face who has. Specific implementation issues aside, one of my own theories is the the concept isn't that useful, for two reasons: 1. Pulling the raw block structure from the production LUN(s) is a sequential read-only process. This it would severely impact the generally random read/write process from the production system. Head contention would ensue with two so different usage patterns. 2. We can't do a selective restore on the file level, it's the entire LUN or nothing. [SNIP] Again, these are just my own theories. I've discussed them with collegues, but noone can say whether I'm right or wrong really. I'd appreciate any comments. /charles I think you pretty much nailed it. In it's time serverless backup was hyped by marketing, but in reality the advantages never really materialised. Speed increases could only be reached when the bottleneck is the SAN itself. Usually that's not the case. Add to that the lack of meta-data in backups, the LUN/zone handling, error recovery and block level access, and you get very complex and limited situations. It's simply a lot easier to use a dedicated backup server and maybe a number of agents to backup the data. One form of 'serverless' backup that can work is NAS appliances (e.g. NetApp) that have enough intelligence to backup their disks at filesystem level. Rob |
#4
|
|||
|
|||
On Sun, 28 Nov 2004 11:36:41 GMT, "Charles Morrall"
wrote: When SAN concept started to gain some market exposure circa 1999 (to me at least), there was much talk about one of the real benefits, namely server-free backup. The LUN(s) on a production system would be directly backed up to tape over fibre channel, not passing any host. To this day, I have never implemented it, or talked to anyone face to face who has. Specific implementation issues aside, one of my own theories is the the concept isn't that useful, for two reasons: 1. Pulling the raw block structure from the production LUN(s) is a sequential read-only process. This it would severely impact the generally random read/write process from the production system. Head contention would ensue with two so different usage patterns. 2. We can't do a selective restore on the file level, it's the entire LUN or nothing. And: 3. Ensuring your LUN is internally consistent at the application level requires freezing out the hosts while you back up the LUN. 4. If you build your filesystem over multiple LUNs for performance or convenience, even having a LUN image is pretty useless! You need a coherent set of LUNs. Once you've bitten (either or both of) those bullets, you may as well have the server do the backup since it's not able to be doing anything useful while your spiffy "serverless" setup runs! One mo 5. Not all data is created equal. Your production data needs to be backed up religiously, but your user's home directories (say) can be dealt with perhaps twice-weekly, and a "reference" application maybe needs to be backed up even less frequently. More to the point, you don't want to have to waste time restoring the miscellany following a disaster: you want the production stuff back ASAP, and the rest after that! Another approach is to create snapshot LUNs within the storage subsystem, mounting the snapshot on a backup host and the copying the LUN to a backup medium (disk or tape). This makes much more sense to me. Although head contention is still a risk, it might be possible to throttle the backup process. In a server-free environment, the major point is the speed of the backup. If you throttle it, well what's the point?. This snapshot approach is viable, albeit still without metadata. In particular, if you have "spare" storage hanging around to protect against some kind of disaster, a snapshot sync between the two systems is valuable, especially if the machines are located physically apart from each other. So your backup machine has a snapshot of the production machine as of (say) midnight last night. However, once on the backup machine, backing up the opaque LUNs is pretty pointless. You may as well use a file-system backup (where possible) to gain the metadata. After all, the backup system isn't doing anything essential, otherwise it's not a backup system! [ Snip ] Again, these are just my own theories. I've discussed them with collegues, but noone can say whether I'm right or wrong really. I'd appreciate any comments. You're right. Serverless backup to secondary media on SANs was never a useful concept. Now, shared-filesystem SANs are another matter, but here why not just add another server to the shared-filesystem to handle the task. (Which is what, effectively, happens with backup-in-the-NAS-box implementations: you're creating a virtual two-node shared FS: the exported NAS thing, and the internal realization that get's backed up). /charles Malc. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Free Backup Software | Paul Schilter | Dell Computers | 3 | January 18th 05 08:45 PM |
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit, Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new ! | vvcd | AMD x86-64 Processors | 0 | September 17th 04 09:07 PM |
Some general questions about backup systems, mainly speed of restore | Rob Nicholson | Storage & Hardrives | 6 | April 19th 04 07:33 PM |
Continued: Putting together a Lower-Mid End Server | Arifi Koseoglu | Asus Motherboards | 2 | February 20th 04 01:34 PM |
64 bit - Windows Liberty 64bit, Windows Limited Edition 64 Bit,Microsoft SQL Server 2000 Developer Edition 64 Bit, IBM DB2 64 bit - new! | TEL | Overclocking AMD Processors | 0 | January 1st 04 06:59 PM |