Computer Associates BABNWUP900NE6 Administration Guide - Page 47

Segmenting Your Network, over several days.

Page 47 highlights

Defining Data-transfer Requirements Segmenting Your Network In many cases, you can make better use of your existing network bandwidth by placing BrightStor ARCserve Backup servers on different subnets. In the absence of subnets, all backup data has to cross a single network to reach the BrightStor ARCserve Backup servers. In effect, every piece of data travels sequentially to every node on the network. When you subnet your network, in effect you create two or more networks of equal speed, each of which handles a fraction of the backup data. Data travels in parallel. In our example, if we backed up 500 GB on two subnets instead of 1 Terabyte on the entire network, we could back up twice as fast. Each subnet could transfer its 500 GB at 36 GB per hour for a total elapsed time of 14 hours (versus 28 hours). In our 5-hour backup window, we could transfer 360 GB, which, though not enough, is still far better than the 180 GB we could attain over a network that is not subnetted. Segmenting Your Data Nothing forces you to treat all of your organization's data as a single unit. It often makes better sense to segment the data into logically related chunks before trying to back it up. This reduces the time required for any single storage operation, makes better use of short backup periods and works better on slow networks. You still back up all of your data. You just do it in a series of shorter operations spread over several days. We might, for instance, back up 20% of the 1 Terabyte of data in our example each night, Monday through Saturday. In the course of a week, this approach would back up our entire 1 Terabyte across the 100Base-T network, without exceeding the daily 5-hour backup period. As an added benefit, the compact backup elements make locating and restoring our data faster and easier by reducing the scope of searches. The downside of this approach is that the entire data will not be backed up daily. Most organizations cannot afford to not have daily backups of complete data; therefore, this approach may not be suitable. Planning 2-9

  • 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
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330
  • 331
  • 332
  • 333
  • 334
  • 335
  • 336
  • 337
  • 338
  • 339
  • 340
  • 341
  • 342
  • 343
  • 344
  • 345
  • 346
  • 347
  • 348
  • 349
  • 350
  • 351
  • 352
  • 353
  • 354
  • 355
  • 356
  • 357
  • 358
  • 359
  • 360
  • 361
  • 362
  • 363
  • 364
  • 365
  • 366
  • 367
  • 368
  • 369
  • 370
  • 371
  • 372
  • 373
  • 374
  • 375
  • 376
  • 377
  • 378
  • 379
  • 380
  • 381
  • 382

Defining Data-transfer Requirements
Planning
2–9
Segmenting Your Network
In many cases, you can make better use of your existing network bandwidth by
placing BrightStor ARCserve Backup servers on different subnets. In the absence
of subnets, all backup data has to cross a single network to reach the BrightStor
ARCserve Backup servers. In effect, every piece of data travels sequentially to
every node on the network. When you subnet your network, in effect you create
two or more networks of equal speed, each of which handles a fraction of the
backup data. Data travels in parallel.
In our example, if we backed up 500 GB on two subnets instead of 1 Terabyte on
the entire network, we could back up twice as fast. Each subnet could transfer its
500 GB at 36 GB per hour for a total elapsed time of 14 hours (versus 28 hours). In
our 5-hour backup window, we could transfer 360 GB, which, though not enough,
is still far better than the 180 GB we could attain over a network that is not
subnetted.
Segmenting Your Data
Nothing forces you to treat all of your organization’s data as a single unit. It often
makes better sense to
segment
the data into logically related chunks before trying
to back it up. This reduces the time required for any single storage operation,
makes better use of short backup periods and works better on slow networks. You
still back up all of your data. You just do it in a series of shorter operations spread
over several days.
We might, for instance, back up 20% of the 1 Terabyte of data in our example each
night, Monday through Saturday. In the course of a week, this approach would
back up our entire 1 Terabyte across the 100Base-T network, without exceeding the
daily 5-hour backup period. As an added benefit, the compact backup elements
make locating and restoring our data faster and easier by reducing the scope of
searches.
The downside of this approach is that the entire data will not be backed up daily.
Most organizations cannot afford to not have daily backups of complete data;
therefore, this approach may not be suitable.