2007-12-27 16:15
feidang
TSM 的几个概念
VEREXISTS: Specifies the number of object copies, or versions, to keep. This
number includes active and inactive object copies.
RETEXTRA: Specifies how many days to keep inactive object copies. When
an object status changes from active to inactive, it will be kept for retextra
days and then removed. It is important to note that the retention period starts
from when the object copy becomes inactive, not from its original backup
date.
VERDELETED: Specifies how many object copies are to be kept in Tivoli
Storage Manager when an object has been deleted on the client.
RETONLY: Specifies how many days to keep the last object copy in Tivoli
Storage Manager when the object has been deleted on the client before.
请高人指点,最好举例子来描述一下,谢谢
2007-12-27 16:35
feidang
[url]http://www.ifpubs.com/books/download/publib.boulder.ibm.com/tividd/td/smaixn/gc32-0769-02/zh_cn/html/anrarf52295.htm[/url]
2007-12-27 17:31
feidang
举个例子:
客户环境:VERExits=3 VERDeleted=2 RETExtra=30 RETOnly=90
假设有个文件File,每天中午12:00被修改,自动备份发生在下午18:00,
第一天备份完成后,tsm server将有该文件的一个版本:version1 (该version为active);
第二天18:00后,tsm server将有该文件的第二个版本: version2 (该version 为active),而第一天备份的version1将变成inactive,
第三天18:00后,tsm server将有该文件的第三个版本:Version3(该version 为active),而第一天的version1,第二天的version2将都是inactive。
第四天18:00后,tsm server 将有该文件的第四个版本:Version4(该version为active),而第二天的version2,第三天的version3将都是inactive。注意一下,这时当备份成功后,第一天的version1将会被expire
2007-12-27 17:38
feidang
还有几个问题:
1. expire 的版本 ,是不是就被删除了?也就是说,如果VERExits=3,每个版本 只能保存3天了?
2. inactive 的版本,能否用来恢复?
3. 一个文件 可以在client 上被删除了,那对于数据库呢?
4. VERExists 和在建 policy domain时设置的,备份保留时间,有什么区别呢?
[[i] 本帖最后由 feidang 于 2007-12-27 17:45 编辑 [/i]]
2007-12-27 20:45
jiangxh
1,如果你不是天天备份?就不是三天的概念,三个版本保留的时间
2,当然可用来恢复,否则还有什么意义啊?
3,不明白你的意思!
4,verexists应该在polict domain里面!
2007-12-28 10:43
feidang
[quote]原帖由 [i]jiangxh[/i] 于 2007-12-27 20:45 发表 [url=http://www.loveunix.com/redirect.php?goto=findpost&pid=750295&ptid=80206][img]http://www.loveunix.com/images/common/back.gif[/img][/url]
1,如果你不是天天备份?就不是三天的概念,三个版本保留的时间
2,当然可用来恢复,否则还有什么意义啊?
3,不明白你的意思!
4,verexists应该在polict domain里面! [/quote]
非常感谢!
3. 这几个参数,对数据库,是不是就不管用了?
4. 在建policy domain时,要设置备份时间(比如30天)和归档时间,verexists 是不是 <=30 ?
2007-12-28 11:34
f_y_l
[quote]原帖由 [i]feidang[/i] 于 2007-12-28 10:43 发表 [url=http://bbs.loveunix.net/redirect.php?goto=findpost&pid=750407&ptid=80206][img]http://bbs.loveunix.net/images/common/back.gif[/img][/url]
非常感谢!
3. 这几个参数,对数据库,是不是就不管用了?
4. 在建policy domain时,要设置备份时间(比如30天)和归档时间,verexists 是不是 [/quote]
3. 对数据库备份一样有用。TSM SERVER把每一个数据库备份当成一个新文件。策略对这些文件一样起作用。
4. 建policy domain时,设置备份时间(比如30天)和归档时间,和管理类中的verexists等设置是两回事。正常情况下TSM用verexists等设置管理备份。当管理员删除了管理类后,TSM会用policy domain的设置管理备份的失效。
2007-12-28 12:26
feidang
我现在打算是,周日做数据库全备份,周一-周六,增量,
VERExits=2 VERDeleted=1 RETExtra=30 RETOnly=30
是否合理?
比如,我是12月30日 星期天 晚上10点开始做备份,
星期一 晚上10点之前,TSM 存在 version1,active,
星期二 晚上10点之前,TSM 存在 version2,active, verision1,inactive。
星期三 晚上10点之前,TSM 存在 version3,active,version2 ,inactive,version1,expire;
如果,星期三 晚上8点我数据丢失,需要恢复,能恢复到最新的数据是哪天的?
[[i] 本帖最后由 feidang 于 2007-12-28 12:35 编辑 [/i]]
2007-12-28 13:37
f_y_l
[b]TSM SERVER把每一个数据库备份当成一个新文件[/b]
每一个数据库备份,不管全备,增备,哪一次备份,TSM都认为一个新文件,有一个唯一的文件名。对同名文件才有不同的版本。
2007-12-28 14:25
feidang
[quote]原帖由 [i]f_y_l[/i] 于 2007-12-28 13:37 发表 [url=http://www.loveunix.com/redirect.php?goto=findpost&pid=750481&ptid=80206][img]http://www.loveunix.com/images/common/back.gif[/img][/url]
TSM SERVER把每一个数据库备份当成一个新文件
每一个数据库备份,不管全备,增备,哪一次备份,TSM都认为一个新文件,有一个唯一的文件名。对同名文件才有不同的版本。 [/quote]
非常感谢!
也就是说,对数据库备份,VERExists实际上是不管用了?只看RETExtra,如果RETExtra=30,其实就是保存30天的备份了
how does the Tivoli Storage Manager determine what a
unique version is? A backup object is considered unique based onNODE_NAME, FILESPACE_NAME, HL_NAME, LL_NAME.
When a backup data object is sent to the Tivoli
Storage Manager server, it has the same NODE_NAME, FILESPACE_NAME,
HL_NAME, LL_NAME as an existing backup data object. The new data object
becomes the ACTIVE_VERSION, and the older version changes state and
becomes an INACTIVE_VERSION.
[[i] 本帖最后由 feidang 于 2007-12-28 16:14 编辑 [/i]]
页:
[1]
Powered by Discuz! Archiver 5.5.0
© 2001-2006 Comsenz Inc.