|
Home > Archive > Data Storage > November 2004 > server-free backup, is it useful?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
server-free backup, is it useful?
|
|
| Charles Morrall 2004-11-28, 7:45 am |
| 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
| |
| Rob Turk 2004-11-29, 7:45 am |
| "Charles Morrall" <charles.morrall@telia.com> wrote in message
news:dLiqd.122857$dP1.432059@newsc.telia.net...
> 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
| |
|
| In article <dLiqd.122857$dP1.432059@newsc.telia.net>,
charles.morrall@telia.com says...
>
>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
>
the real life "killer app" that we're seeing is the ability to
back up DIRECTLY to the new generation of D2D2T (disk to disk
to tape) appliances (like the Overland REO)
i'm told that some of the software companies (ie Veritas & CA)
are working on this because it would allow multiple servers to
backup directly to the D2D appliance concurrently across the
LAN (iSCSI) without going back through the "backup server"
i think that it could be "kluged" together now but that there
will soon be an "approved" solution AND that it would also
support Fibre Channel
_____ . .
' \\ . . |>>
O// . . |
\_\ . . |
| | . . . |
/ | . www.EvenEnterprises.com . . . |
/ .| aseltzer@EvenEnterprises.com . . . |
/ . | 310-544-9439 / 310-544-9309 fax . . . o
----------------------------------------------------------------------
Authorized - DIRECT VAR/VAD/Distributor for new SCSI/FC-AL peripherals
NAS/SAN/RAID from HP, IBM, Seagate, EMC, QLogic, ATL, OverLand Data
| |
| Malcolm Weir 2004-11-29, 5:45 pm |
| On Sun, 28 Nov 2004 11:36:41 GMT, "Charles Morrall"
<charles.morrall@telia.com> 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 more:
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.
|
|
|
|
|