[no subject]
2015-10-04 18:07:24
ADSM should displace the notion of full vs. incremental backups. However, old
habits die hard.
For faster restores, it may make sense to think about your data in a new way:
not all data is equally important. If you decide which data really has a rapid
restore requirement, and you know (not think you know, but know) that the
default way that ADSM handles data does not provide rapid enough restore, you
can treat that data differently. One possible answer is to collocate a clients
data on tape. In this way, it is only necessary to mount a tape or two
(depending on the tape technology you have) to restore the data. Collocating
data costs you on the backup performance side (not much if your migrations to
tape occur after backup processing is complete, assuming you have enough disk
pool to hold a day's incremental backups), but saves you on the restore side.
What sort of tape drives do you have? Have you tried a full disk restore to
determine how long it is actually taking?
Kelly
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
|
Previous by Date: |
Incremental Backup failures I am running an OS/2 client (Ver 2, Rel 1, Level .2) backing up to an I am running an OS/2 client (Ver 2, Rel 1, Level .2) backing up to an MVS Server (Ver 2, Rel 1, Level .12) and am doing an incremental backing up of a number of OS/2 Warp servers every night., Peter Piechocinski at CLAPO002 |
Next by Date: |
Full volume backups, ZEIDA HEAVENER [SMTP:ZHEAVENER |
Previous by Thread: |
Incremental Backup failures I am running an OS/2 client (Ver 2, Rel 1, Level .2) backing up to an I am running an OS/2 client (Ver 2, Rel 1, Level .2) backing up to an MVS Server (Ver 2, Rel 1, Level .12) and am doing an incremental backing up of a number of OS/2 Warp servers every night., Peter Piechocinski at CLAPO002 |
Next by Thread: |
[no subject], Unknown |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|