1.5配置NetBackup数据库备份策略

建议定期备份NetBackup的索引数据库Catalog，以确保故障时的有效恢复。
从Javaconsole可以进入备份NetBackup内部数据库配置窗口，如下图：

点击Configure Catalog Backup后,出现下图

点击下一步，出现下图

输入策略名称后，出现下图

选择增量还是全量备份后，出现下图

设置备份频率后，出现下图

设置备份时间窗口后，出现下图

输入DR保护文件保存路径后，出现下图

设置不需要发送邮件后，出现下图

完成配置后，从Policies进入hot-catalog策略的属性

修改和配置存储单元后，NetBackup数据库备份策略配置完成。

原文地址：https://www.cnblogs.com/yihr/p/9127038.html

时间： 2024-08-30 14:37:04

1.5配置NetBackup数据库备份策略的相关文章

SQL Server 数据库备份策略，第一周运行失败的原因

一般生产库,采用 每10分钟备份Log,每天备份Diff,每周备份Full的策略. 同时存在异地备份.异地备份可使用SQL Server本身的cmdshell存储过程,调用系统命令. 在为新数据库,建立备份策略后,往往日志开始首先备份. 这时,若新库之前没有Full备份,则Log备份,Diff备份均失败.Diff和Log备份都依赖于完整备份,而一个新库是没有完整备份的. 所以策略运行第一周会失败. 为了避免这个问题,要手工运行下Full备份. 新库,若没备份过,如下图.

MySQL主从同步配置实现数据库备份

作为数据库的主要备份手段,主从同步能实现从主库(即当前使用的业务数据库)异步同步数据到从库(备份库),当主库数据库或主机出现当机不能启动时,可以通过切换到从库实现业务系统的快速恢复. 首先介绍一下我的环境,我有一个已经使用中的MySQL数据库A,然后我新装了一台MySQL数据库B作为A的从库. 一.master库A设置 先修改mysql的配置 vim /etc/my.cnf 插入下面2行 server-id=1   #这个ID是唯一的,不能和其他的主库或者从库一样 log-bin=mysql-b

大数据量的Mysql数据库备份策略

Centos下mysql常用的三种备份方法 http://www.centoscn.com/CentOS/Intermediate/2013/0807/1160.html xtrabackup备份 http://7567567.blog.51cto.com/706378/706242 Xtrabackup安装及使用 http://www.cnblogs.com/cosiray/archive/2012/03/02/2376595.html

1.4 配置备份策略（Policy）

1.1 配置备份策略(Policy) 一个备份策略由四部分组成. Attributes(属性) Policy是否Active Policy类型 由此Policy产生的任务的优先级 使用的Storage Unit和Volume Pool Schedules(备份日程表) 对于自动备份,列出在此Policy中所有Client的备份时间 对于用户备份或归档,列出用户可以在何时提交任务 Backup Selections(备份文件列表) 列出所有自动备份的文件或目录: 对于用户发起的备份,不必列出,因为

某系统数据库的增量备份策略恢复测试过程

上半年,公司服务器虚拟化项目已经上线,所以近期的主要工作重心以P2V(物理机到虚拟机)的迁移为主,作为业务系统核心的后台数据库的迁移更是这项工作的重中之重. 本次数据库的迁移工作主要包含两部分的内容:一是跨平台(windows2003到OEL6)的数据库版本升级(Oracle 9.2.0.6到Oracle 11.2.0.4):二是数据迁移.由于这些变迁,伴随着发生了许多操作方式(习惯)的变化,最显著的一点就是备份方式的变更了.之前的备份方式是采用exp逻辑导出的方式,就目前业务运行的情形来看,此

Oracle 数据库备份和恢复配置

可能的失败及其解决方法 失败类型 我们坑你遇到的失败或错误分为两大类:物理和逻辑.物理错误一般是硬件错误或使用数据库的应用程序中的软件错误,而逻辑错误一般在终端用户级别(数据库用户和管理员). 按从轻到重.易恢复到难恢复排列: 语句失败:用户的SELECT或DML语句因权限.语法或资源限制而失败. 用户错误:用户误删了一个表或表中的行. 用户进程失败:与数据库的连接因为客户端断开或未预料的停机而失败. 网络失败:客户机和服务器(数据库)之间的网络连接因为网络硬件或协议错误而失败. 实例失败:数据

SQL Server 维护计划实现数据库备份（策略实战）

一.背景 之前写过一篇关于备份的文章:SQL Server 维护计划实现数据库备份,上面文章使用完整备份和差异备份基本上能解决数据库备份的问题,但是为了保障数据更加安全,我们需要再次完善我们的备份计划: 下面这篇文章主要加入了日志备份,并对设计备份的频率和设计命名规范等问题进行实战: 二.最佳实践 (一) 备份计划 1) 每周星期日的2:00:00执行数据库的完整备份: 2) 每周星期一至星期六每天的2:00:00执行数据库的差异备份: 3) 每天在8:00:00和23:59:59之间.每1小时

SQL SERVER 数据库备份的三种策略及语句

1.全量数据备份    备份整个数据库,恢复时恢复所有.优点是简单,缺点是数据量太大,非常耗时 全数据库备份因为容易实施,被许多系统优先采用.在一天或一周中预定的时间进行全数据库备份使你不用动什么脑筋.使用这种类型的备份带来的问题是非常缺乏灵活性,而且当数据库被冲掉后,你面临丢失大量数据的潜在威胁.例如,假设你每天在午夜备份数据库. 如果服务器在晚上11点崩溃了,你将丢失前面23个小时对数据所做的全部修改.对大多数系统来说,这是无法接受的.对此规则,为数不多的例外如下: 1.系统中所存的数据可以

使用lsyncd配置数据库备份多异地同步

lsyncd配置文件 settings { logfile = "/var/log/lsyncd.log", --日志路径 status = "/var/log/lsyncd.status", --状态文件 pidfile = "/var/run/lsyncd.pid", --pid文件路径 statusInterval = 1, --状态文件写入最短时间 maxProcesses = 4, --最大进程 maxDelays = 1 --最大延迟