HP ProLiant CL1850 Compaq ProLiant CL1850 Software User Guide - Page 79

Backing Up Your Cluster

Get HP ProLiant CL1850 PDF manuals and user guides View all HP ProLiant CL1850 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 79 highlights

5-14 Compaq ProLiant CL1850 Software User Guide Backing Up Your Cluster The need for cluster backup is essential for both business-critical and nonbusiness-critical data. As data becomes an increasingly valued company asset, it needs to be backed up on a regular basis. The process of backing up data will ensure that a company's assets are secure and available when a disaster strikes. The cluster itself provides a high degree of application availability but does not prevent a user from deleting or corrupting a file or set of files. Backing up a cluster's data will increase the overall level of data availability. Compaq currently suggests the use of one of the following solutions: s The first solution uses two tape backup subsystems, one tape backup subsystem attached to each server node. s The second solution shares a SCSI tape backup subsystem between the two server nodes. Each solution has its limitations from both the hardware and software perspective. The limitations are due to the fact that tape backup software for use with Windows NT has not been updated for clustering. As Windows NT clustering becomes more prevalent, tape backup vendors will update their software to become cluster-aware. The lack of cluster-aware tape backup software presents the user with two problems: s First, there may be an inability to locate files when the cluster is in a degraded state. For example, assume server node 1 owns a shared drive, G:. A tape backup is performed from server node 1 and drive G: is backed up. At some point in the future, a need arises to restore some files to drive G:. However, drive G: is in a failover state and is currently owned by server node 2. An attempted restoration of the files from server node 1 may fail if the tape backup software is unable to comprehend the shared characteristic of drive G:. s Second, if a failover or failback event occurs while a backup is executing, you may not be able to continue the backup; you may be required to restart the backup from the beginning. For example, if you are backing up drive G: from server node 1 and a failover event moves drive G: to server node 2, the backup process will abort since drive G: is no longer accessible from server node 1. The backup process, if configured as a cluster group and if the backup software supports a restart, can possibly be automatically restarted on server node 2. Still, the restarted backup will start at the beginning; the data placed on tape by the interrupted backup process on server node 1 is lost.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
5-14
Compaq ProLiant CL1850 Software User Guide
Backing Up Your Cluster
The need for cluster backup is essential for both business-critical and non-
business-critical data. As data becomes an increasingly valued company asset,
it needs to be backed up on a regular basis. The process of backing up data
will ensure that a company’s assets are secure and available when a disaster
strikes. The cluster itself provides a high degree of application availability but
does not prevent a user from deleting or corrupting a file or set of files.
Backing up a cluster’s data will increase the overall level of data availability.
Compaq currently suggests the use of one of the following solutions:
■
The first solution uses two tape backup subsystems, one tape backup
subsystem attached to each server node.
■
The second solution shares a SCSI tape backup subsystem between the
two server nodes.
Each solution has its limitations from both the hardware and software
perspective. The limitations are due to the fact that tape backup software for
use with Windows NT has not been updated for clustering. As Windows NT
clustering becomes more prevalent, tape backup vendors will update their
software to become cluster-aware.
The lack of cluster-aware tape backup software presents the user with two
problems:
■
First, there may be an inability to locate files when the cluster is in a
degraded state. For example, assume server node 1 owns a shared drive,
G:. A tape backup is performed from server node 1 and drive G: is
backed up. At some point in the future, a need arises to restore some
files to drive G:. However, drive G: is in a failover state and is currently
owned by server node 2. An attempted restoration of the files from
server node 1 may fail if the tape backup software is unable to
comprehend the shared characteristic of drive G:.
■
Second, if a failover or failback event occurs while a backup is
executing, you may not be able to continue the backup; you may be
required to restart the backup from the beginning. For example, if you
are backing up drive G: from server node 1 and a failover event moves
drive G: to server node 2, the backup process will abort since drive G: is
no longer accessible from server node 1. The backup process, if
configured as a cluster group and if the backup software supports a
restart, can possibly be automatically restarted on server node 2. Still,
the restarted backup will start at the beginning; the data placed on tape
by the interrupted backup process on server node 1 is lost.