designing a backup architecture that actually works

29
Hosted by Designing a Backup Architecture That Actually Works W. Curtis Preston President/CEO The Storage Group

Upload: hamal

Post on 25-Feb-2016

30 views

Category:

Documents


0 download

DESCRIPTION

Designing a Backup Architecture That Actually Works. W. Curtis Preston President/CEO The Storage Group. What will we cover?. What are the design options? LAN-based, LAN-free, Client-free, Server-free NDMP Using disk in your backup system What should I do with them? Sizing your server. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Designing a  Backup Architecture  That Actually Works

Hosted by

Designing a Backup Architecture That Actually WorksW. Curtis PrestonPresident/CEOThe Storage Group

Page 2: Designing a  Backup Architecture  That Actually Works

Hosted by

What will we cover?

What are the design options?• LAN-based, LAN-free, Client-free, Server-free• NDMP• Using disk in your backup system

What should I do with them?• Sizing your server

Page 3: Designing a  Backup Architecture  That Actually Works

Hosted by

What are the design options?

Page 4: Designing a  Backup Architecture  That Actually Works

Hosted by

SAN: LAN-free, Client-free, and Server-free backupNAS: NDMP filer to self, filer to filer, filer to server, & server to filer

Eth

erne

t

Data General

BackupServer

IBM

Backup Client

IBM

Backup Client

FC

FC

Router

Library

SCSISCSI

Disk Array

NAS ServerFCFC

FC Switchor Hub

FCNAS Server

NAS Server

LibraryFC Switch

or Hub

FC

SCSI

Library

FC

NASSAN SAN

Virtual tape

Page 5: Designing a  Backup Architecture  That Actually Works

Hosted by

LAN-based backupsStandard methodCentral backup server

with network clients backing up across the LAN

Simplest, least expensive design

latigid

HEWLETTPACKARD

Data General

BackupServer

TapeLibrary

Disk Disk Disk

Page 6: Designing a  Backup Architecture  That Actually Works

Hosted by

LAN-free backups How does this work?

• SCSI Reserve/Release• Third-party queuing

system

Levels of drive sharing Restores

IBM

IBM

Disk

Disk

IBM

Disk

TapeLibrary

SCSI/FCRouter

SCSI

SCSI

SCSI

SCSI

FC

FC Switch

FC

FC

FC

Page 7: Designing a  Backup Architecture  That Actually Works

Hosted by

Client-free backups

Transaction Logs

TapeLibrary

DataSrvr

BackUpSrvr

B

primarydisk set

backupmirror

1

3

2a

TapeLibrary

BackUpSrvr

A2c

2b

LAN

TapeLibrary

DataSrvr

BackUpSrvr

primarydisk set

backupmirror

Transaction Logs

2

1Tape

Library

BackUpSrvr

A

LAN

Backup transaction logs to disk

Establish backup mirrorTape

LibraryDataSrvr

BackUpSrvr

primarydisk set

backupmirror

4a 4b

Transaction Logs

1

2

3Tape

Library

BackUpSrvr

A

LAN

Split backup mirror and back it up

Page 8: Designing a  Backup Architecture  That Actually Works

Hosted by

Client-free restoresTape

LibraryDataSrvr

BackUpSrvr

primarydisk set

backupmirror

Transaction Logs

1b

2c

TapeLibrary

BackUpSrvr

A

LAN

2b

2a

1a

TapeLibrary

DataSrvr

BackUpSrvr

Transaction Logs

1

B A

4

32

5TapeLibrary

BackUpSrvr

A

LAN

TapeLibrary

DataSrvr

BackUpSrvr

primarydisk set

backupmirror

Transaction Logs

TapeLibrary

BackUpSrvr

A

LAN

Page 9: Designing a  Backup Architecture  That Actually Works

Hosted by

Server-free backups

Server directs client to take a copy-on-write snapshot

Client and server record block and file associations

Server sends XCOPY request to SAN

TapeLibrary

DataSrvr

SANw/xcopysupport

primarydisk set

backupmirror

orsnapshot

3

Transaction Logs

1

2Tape

Library

BackUpSrvr

A

LAN

Virtual DiskProvided byDisk Array

Block D

Block EBlock F

FileB

Block A

Block B

Block C

FileA

Page 10: Designing a  Backup Architecture  That Actually Works

Hosted by

Server-less Restores Changing

block locations

Image levelrestores

File levelrestores

Virtual DiskProvided byDisk Array

Block D

Block EBlock F

FileB

Block A

Block B

Block C

FileA

Tape

Snapshotor

Mirror

Block D

Block EBlock F

Block A

Block B

Block C

Virtual DiskProvided byDisk Array

Block D

Block E Block F

FileB (deleted)

Block A

Block B

Block C

FileA

Snapshotor

Mirror

Block A

Block B

Block C

Block D

Block EBlock F

Tape

Backup Restore

Page 11: Designing a  Backup Architecture  That Actually Works

Hosted by

Backing up a filer: NDMP Filer to self Filer to filer Filer to

server Server to

filer Similar to

server-free backups

LAN

Filer Filer Filer

BackupServer

Tape library Tape libraryTape library

OtherServer

Server to Filer

Filerto

Self

Filer to Filer

NDMP tapelibrary

Filerto

libraryFiler toServer

Page 12: Designing a  Backup Architecture  That Actually Works

Hosted by

Using NDMPLevel of functionality depends on the DMA

and filer vendors•Robotic Support•Filer to Library Support•Filer to Server Support•Direct access restore support• Image level backup

Page 13: Designing a  Backup Architecture  That Actually Works

Hosted by

Using diskATA-based storage arrays as low as $5/GB

(disk only, needs filesystem)Special function arrays

• Quantum DX-30 looks and behaves like a Quantum P1000. Can be used as target for “tape-based” backups (3 usable TB, $55K list, or $18/GB)

• NetApp R100 looks like other NetApp filer. Target for SnapVault and disk-based backups, source for SnapMirror (9+ usable TB, $175K list, or $18/GB)

Page 14: Designing a  Backup Architecture  That Actually Works

Hosted by

First Step: Backup to disk Use as a target for all

incremental backups. (Full, too, if you can afford it)

For off-site storage, duplicate all disk-based backups to tape.

Leave disk-based backups on disk.

Page 15: Designing a  Backup Architecture  That Actually Works

Hosted by

Second Step: Mirror to disk Use “dumb” arrays and

smart volume managers and replication software.

Use smart arrays with replication built into them.

Most valuable methods have built in point-in-time snapshots.

Mirror to disk, then backup to tape, or mirror to another disk!

Page 16: Designing a  Backup Architecture  That Actually Works

Hosted by

Sizing the backup system

Page 17: Designing a  Backup Architecture  That Actually Works

Hosted by

Give it enough powerNot enough tape drivesTape drives that aren’t

fast enoughNot enough slots in the

tape libraryNot enough bandwidth

to the server

Page 18: Designing a  Backup Architecture  That Actually Works

Hosted by

Don’t give it too much powerStreaming tape drives must be

streamed If you don’t, you will wear out

your tape drives and decrease aggregate performance

Must match the speed of the pipe to the speed of the tape

You can actually increase your throughput by using fewer tape drives

Page 19: Designing a  Backup Architecture  That Actually Works

Hosted by

Server Size/Power

I/O performance more important than CPU power

CPU, memory, I/O expandability paramount

Avoid overbuying by testing prospective server under load

Page 20: Designing a  Backup Architecture  That Actually Works

Hosted by

Catalog/database Size Determine number of files (n) Determine number of days in cycle (d) (A cycle is a full backup and its associated incremental

backups) Determine daily incremental size (i = n * .02) Determine number of cycles on-line (c) 150-250 bytes per file, per backup Use a 1.5 multiplier for growth and error Index Size = (n + (i*d)) * c * 250 * 1.5

Page 21: Designing a  Backup Architecture  That Actually Works

Hosted by

Number of Tape Drives – All Tape LAN-based Backup

• Buy twice as many backup drives as your network will support

• Use only as many drives as the network will support (You will get more with less)

• Use the other half of the drives for duplicating

Page 22: Designing a  Backup Architecture  That Actually Works

Hosted by

Number of Drives – Disk/Tape Combo

LAN-based Backup• Buy disk system large enough to satisfy entire

on-site retention period without deletion.• Buy enough tape drives to duplicate each

night’s backups. Duplicate each night’s backups to tape, then take them out and send them offsite.

• Library should be large enough to hold three to four days of backups. (Only needs to hold duplicated tapes until they’re sent off-site.)

Page 23: Designing a  Backup Architecture  That Actually Works

Hosted by

Number of Drives – LAN-Free backup Most large servers have enough I/O bandwidth

to back themselves up within a reasonable time

Usually a simple matter of mathematics:• 8 hr window, 8 TBs = 1 TB/hr = 277 MB/s• 30 10 Mb/s drives, 15 20 MB/s drives

Must have sufficient bandwidth to tape drives Filesystem vs. raw recoveries Allow drives and time for duplicating

Page 24: Designing a  Backup Architecture  That Actually Works

Hosted by

Library Size - slots (all tape environment) Should hold all onsite tapes On-site tapes automatically expire and get

reused Only offsite tapes require phys. mgmt.

Should monitor library via a script to ensure that each pool has enough free tapes before you go home

Watch for those downed drive messages

Page 25: Designing a  Backup Architecture  That Actually Works

Hosted by

Library Size - slots (disk/tape environment) Do all backups to disk wherever possible. Library only needs to hold the latest set of

copies (three or four days worth). Disk-based backups automatically expire and

space gets reused. Only off-site tapes require phys. mgmt. Should monitor library and disk via a script to

ensure that each pool has enough free space before you go home

Watch for those downed drive messages

Page 26: Designing a  Backup Architecture  That Actually Works

Hosted by

Configuring your server

Backup all drives.Make sure you are streaming your

drives.Create an automated monitoring system.Establish standards wherever possible,

and use them!

Page 27: Designing a  Backup Architecture  That Actually Works

Hosted by

Resources

Page 28: Designing a  Backup Architecture  That Actually Works

Hosted by

ResourcesDirectories of products to help you

build a better backup systemhttp://www.storagemountain.com

Send questions to:

[email protected]

Page 29: Designing a  Backup Architecture  That Actually Works

Hosted by

Thank you!

W. Curtis PrestonPresident/CEOThe Storage Group