精华内容
下载资源
问答
  • 关于系统数据库的备份策略
    千次阅读
    2021-06-11 02:06:34

    备份与恢复

    1. 备份策略

    1.1. 备份工具

    一、当数据库数据量不大,且写入操作比较少的情况下,可以采用 mysqldump 方式进行全量备份。
    二、 当数据量较大时,或者InnoDB数据库写入频繁时,建议采用 xtrabackup进行全量备份。
    三、当有增量备份需求时,采用xtrabackup进行增量备份,以降低磁盘空间的消耗。
    四、为了能更灵活的将数据恢复到指定的时间点,使用binlog 作为增量备份。

    1.2. 备份策略

    • 使用 xtrabackup 每七天做一次全量备份,并以 binlog 作为增量备份
    • binlog 保留七天,全量备份保留一个月,超过一个月的保留近一年每个月1号的数据
    • 使用xtrabackup备份时,都是在从库执行
    •一般一个实例仅一个业务数据库,因此不涉及分库备份

    1.3. 数据恢复方式

    1.3.1. 数据库或者数据表误删除情况

    将 binlog和上一次的备份结果拷贝到测试机器,将数据库恢复到drop语句之前的一次事务状态,并通过mysqldump将误删除的数据库或者数据表导出,并导入生产环境的主库。

    1.3.2. 数据库中部分数据被误修改或者删除

    通过查询业务日志,找到被误操作的时间和语句;
    结合binlog和备份,将测试环境数据库恢复到误操作之前,然后交由对于业务运维或者开发导出需要的数据,并写入生产环境的主库。

    1.3.3. 建议

    尽可能不影响现网当前的业务,尽可能快的恢复,尽可能不破坏现有的日志信息。 实际操作中,根据数据量、紧急程度等灵活应变。数据恢复属于高危操作,尽可能避免在生产库直接操作,尽可能避免破坏数据库。

    2. binlog + mysqldump 恢复数据

    2.1.在测试库还原数据 数据备份

    2.1.1. 运行数据插入脚本

    [root@MySQL-1-190 ~]# cat insert.sh
    #!/bin/bash
    id=$(mysql -uroot -p'123456' oracle -e "select id from test order by insert_time desc limit 1 ;" 2>/dev/null |tail -n 1)
    [[ $id =~ ^[0-9]+$ ]] || id=0
    while :
    do
        id=$[id+1]
        uuid=$(cat /proc/sys/kernel/random/uuid)
        mysql -uroot -p'123456' oracle -e "insert into test values ($id,\"$uuid\",now()) ;" 2>/dev/null
        echo "$(date +'%F %T')|$id|$uuid|T" >> run.log
        sleep 0.2
    done
    [root@MySQL-1-190 ~]# bash insert.sh &
    

    2.1.2使用mysqldump备份数据

    [root@MySQL-1-190 ~]# mysqldump -uroot -p --master-data=2 --single-transaction --all-databases > $(date +%F).MySQL-1-190.sql
    

    2.1.3. 模拟误操作删除删除数据

    mysql> delete from test where id < 10 ;
    mysql> delete from test where id between 2100 and 2170 ;
    

    2.2. 在测试库还原数据

    2.2.1. 拷贝备份和所需要的binlog到测试库服务器

    [root@MySQL-1-190 ~]# scp /opt/logs/mysql/MySQL-1-190-bin.000010 $(date +%F).MySQL-1-190.sql 192.168.1.200:/opt/
    [root@MySQL-1-200 opt]# mysql -uroot -p < 2019-06-16.MySQL-1-190.sql
    [root@MySQL-1-200 opt]# grep -m 1 'MASTER' 2019-06-16.MySQL-1-190.sql ## 找到备份的binlog位置点
    -- CHANGE MASTER TO MASTER_LOG_FILE='MySQL-1-190-bin.000010', MASTER_LOG_POS=5547297;
    [root@MySQL-1-200 opt]# mysqlbinlog --database=oracle MySQL-1-190-bin.000010 > res.tmp.sql ## 转换binlog为文本文件
    

    2.2.2. 提取第一次被误删除的数据

    [root@MySQL-1-200 opt]# grep -B 5 "delete from test where id < 10" res.tmp.sql ##  找到第一次误操作的位置点
    BEGIN
    /*!*/;
    # at 5641004
    #190616 20:52:02 server id 1  end_log_pos 5641112 CRC32 0x6c21b22d 	Query	thread_id=19658	exec_time=0	error_code=0
    SET TIMESTAMP=1560689522/*!*/;
    delete from test where id < 10
    [root@MySQL-1-200 opt]# mysqlbinlog --start-position=5547297 --stop-position=5641004 MySQL-1-190-bin.000010 > res1.sql ## 提取需要的binlog日志
    [root@MySQL-1-200 opt]# mysql -uroot -p < res1.sql  ## 应用binlog日志
    [root@MySQL-1-200 ~]# mysql -uroot -p oracle -e "select * from test where id < 10 ;" | awk 'NR!=1{print "insert into test values ("$1",\""$2"\",\""$3,$4"\");" }'  > insert.sql ## 提取数据,使用infile和outfile更简单,但是默认没开启这个功能,因此使用awk来处理
    

    2.2.3. 提取第二次被误删除的数据

    [root@MySQL-1-200 opt]# grep -B 5 "delete from test where id between 2100 and 2170" res.tmp.sql
    BEGIN
    /*!*/;
    # at 6021552
    #190616 20:56:48 server id 1  end_log_pos 6021677 CRC32 0x7bf90013 	Query	thread_id=19658	exec_time=0	error_code=0
    SET TIMESTAMP=1560689808/*!*/;
    delete from test where id between 2100 and 2170
    [root@MySQL-1-200 opt]# mysqlbinlog --start-position=5641004 --stop-position=6021552 MySQL-1-190-bin.000010 > res2.sql
    [root@MySQL-1-200 opt]# mysql -uroot -p < res2.sql
    [root@MySQL-1-200 ~]# mysql -uroot -p oracle -e "select * from test where id between 2100 and 2170 ;" | awk 'NR!=1{print "insert into test values ("$1",\""$2"\",\""$3,$4"\");" }'  >> insert.sql
    [root@MySQL-1-200 ~]# scp insert.sql 192.168.1.190:~/
    

    2.3. 将误删除数据插入原数据库

    mysql> source insert.sql ;
    mysql> select count(*) from test where id<10 ;
    +----------+
    | count(*) |
    +----------+
    |        9 |
    +----------+
    mysql> select count(*) from test where id between 2100 and 2170 ;
    +----------+
    | count(*) |
    +----------+
    |       71 |
    +----------+
    

    3. xtrabackup + binlog

    3.1. 数据备份

    3.1.1. 运行数据插入脚本

    [root@MySQL-1-190 ~]# cat insert.sh
    #!/bin/bash
    id=$(mysql -uroot -p'MySQL.1992' oracle -e "select id from test order by insert_time desc limit 1 ;" 2>/dev/null |tail -n 1)
    [[ $id =~ ^[0-9]+$ ]] || id=0
    while :
    do
        id=$[id+1]
        uuid=$(cat /proc/sys/kernel/random/uuid)
        mysql -uroot -p'MySQL.1992' oracle -e "insert into test values ($id,\"$uuid\",now()) ;" 2>/dev/null
        echo "$(date +'%F %T')|$id|$uuid|T" >> run.log
        sleep 0.2
    done
    [root@MySQL-1-190 ~]# bash insert.sh &
    

    3.1.2. 使用xtrabackup进行增量备

    [root@MySQL-1-190 ~]# xtrabackup --user=backup --password='Backup.1992' --socket=/opt/apps/mysql/tmp/mysql.sock --backup --target-dir=/data/backup/mysql_data/20190617-full/ ## 全量备份
    [root@MySQL-1-190 ~]# xtrabackup --user=backup --password='Backup.1992' --socket=/opt/apps/mysql/tmp/mysql.sock --backup --target-dir=/data/backup/mysql_data/20190617-inc01 --incremental-basedir=/data/backup/mysql_data/20190617-full/  ## 第一次增量
    [root@MySQL-1-190 ~]# xtrabackup --user=backup --password='Backup.1992' --socket=/opt/apps/mysql/tmp/mysql.sock --backup --target-dir=/data/backup/mysql_data/20190617-inc02 --incremental-basedir=/data/backup/mysql_data/20190617-inc01 ## 第二次增量
    

    3.1.3. 模拟误操作(update 语句少了条件)

    mysql> update test set fid="ffd09512-8d11-450b-94ba-6d309b1ee167" ;
    

    3.2. 在测试库还原数据

    3.2.1. 将需要的备份、binlog拷贝到测试库服务器

    [root@MySQL-1-190 ~]# scp -qr /opt/logs/mysql/MySQL-1-190-bin.000010 /data/backup/mysql_data/20190617-* 192.168.1.200:~/backup_data
    [root@MySQL-1-190 ~]# grep bin /data/backup/mysql_data/20190617-*/xtrabackup_binlog_info  ## 查看binlog位置
    /data/backup/mysql_data/20190617-full/xtrabackup_binlog_info:MySQL-1-190-bin.000010   9245580
    /data/backup/mysql_data/20190617-inc01/xtrabackup_binlog_info:MySQL-1-190-bin.000010    9375450
    /data/backup/mysql_data/20190617-inc02/xtrabackup_binlog_info:MySQL-1-190-bin.000010    9514686
    

    3.2.2. 恢复数据到误操作前一个事务

    [root@MySQL-1-200 backup_data]# xtrabackup --prepare --apply-log-only --target-dir=20190617-full/
    [root@MySQL-1-200 backup_data]# xtrabackup --prepare --apply-log-only --target-dir=20190617-full --incremental-dir=20190617-inc01
    [root@MySQL-1-200 backup_data]# xtrabackup --prepare --target-dir=20190617-full --incremental-dir=20190617-inc02
    [root@MySQL-1-200 backup_data]# grep bin 20190617-*/xtrabackup_binlog_info  ## 将xtrabackup备份恢复到指定时间
    20190617-full/xtrabackup_binlog_info:MySQL-1-190-bin.000010   9514686
    20190617-inc01/xtrabackup_binlog_info:MySQL-1-190-bin.000010    9375450
    20190617-inc02/xtrabackup_binlog_info:MySQL-1-190-bin.000010    9514686
    [root@MySQL-1-200 backup_data]# grep bin 20190617-*/xtrabackup_binlog_pos_innodb ## start-pos=9514686
    MySQL-1-190-bin.000010  9514686
    [root@MySQL-1-200 backup_data]# mysqlbinlog MySQL-1-190-bin.000010 | grep -C 5 'set fid="ffd09512-8d11-450b-94ba-6d309b1ee167"' # stop-pos=9638723
    BEGIN
    /*!*/;
    # at 9638723
    #190617  7:45:08 server id 1  end_log_pos 9638859 CRC32 0x02910a15  Query   thread_id=33595 exec_time=0 error_code=0
    SET TIMESTAMP=1560728708/*!*/;
    update test set fid="ffd09512-8d11-450b-94ba-6d309b1ee167"
    /*!*/;
    # at 9638859
    #190617  7:45:08 server id 1  end_log_pos 9638890 CRC32 0x5b1e92ba  Xid = 103146
    COMMIT/*!*/;
    # at 9638890
    [root@MySQL-1-200 backup_data]# mysqlbinlog --start-position=9514686 --stop-position=9638723 MySQL-1-190-bin.000010 --result-file res.sql
    

    3.2.3. 提取误操作前的数据

    [root@MySQL-1-200 backup_data]# /etc/init.d/mysql.server stop
    [root@MySQL-1-200 backup_data]# rm /opt/apps/mysql/data/* -fr
    [root@MySQL-1-200 backup_data]# cp -r 20190617-full/* /opt/apps/mysql/data/ ## 导入xtrabackup数据
    [root@MySQL-1-200 backup_data]# chown -R mysql.mysql /opt/apps/mysql/data/
    [root@MySQL-1-200 backup_data]# /etc/init.d/mysql.server start
    [root@MySQL-1-200 backup_data]# mysql -uroot -p < res.sql ## 导入增量备份数据
    [root@MySQL-1-200 backup_data]# mysqldump -uroot -p --no-create-info oracle test > test.sql ## 导出需要恢复的数据表,不包含创表语句
    

    3.3. 还原被误操作数据

    根据实际情况灵活选择还原方式,比如:
    • 删除被误操作的数据,并将 test.sql 导入数据库
    • 将test.sql导入临时表,使用update命令将被修改的数据还原

    更多相关内容
  • 数据库备份策略.docx

    2021-09-20 18:54:06
    数据库备份策略.docx
  • 数据库备份因为容易实施,被许多系统优先采用。在一天或一周中预定的时间进行全数据库备份使你不用动什么脑筋。使用这种类型的备份带来的问题是非常缺乏灵活性,而且当数据库被冲掉后,你面临丢失大量数据的潜在...
  • 浅谈校园一卡通系统的Oracle数据库备份策略与实现方法.pdf
  • 浅析SQL Server数据库备份系统的备份恢复策略.pdf
  • mysql数据库备份策略

    2011-08-23 16:26:31
    数据库表丢失或损坏的情况下,备份你的数据库是很重要的。如果发生系统崩溃,你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态。本文主要对MyISAM表做备份恢复。
  • 数据备份策略(full backup, differential backup and transaction log backup) 数据备份是为数据恢复服务的,所以建立数据备份计划之前,应先考虑是否能利用该备份有效的恢复数据(在downtime允许的时间范围内).还应先...
  • 无论数据库是运行在Docker,VM或云上,数据库备份都至关重要。话虽如此,但无论对于个人还是组织,如何决定数据库的备份恢复策略,都是一个难题。这要求对于你所用的应用程序、业务逻辑以及成本有个较为深入的了解。...

    作者:瀚高PG实验室(Highgo PG Lab) 丹心明月

     

    对数据库进行备份,是数据库管理的基本要求,是从数据库灾难场景(例如服务器宕机、数据库崩溃或损坏)中恢复数据的基本保证。无论数据库是运行在Docker,VM或云上,数据库备份都至关重要。话虽如此,但无论对于个人还是组织,如何决定数据库的备份恢复策略,都是一个难题。这要求对于你所用的应用程序、业务逻辑以及成本有个较为深入的了解。那么,让我们开始学习,如何理清头绪,从哪里开始以及如何选择PostgreSQL数据库的备份策略。

    假设场景如下:

    这里有一个以PostgreSQL为后台数据库的电子商务应用程序。数据库大小约100GB左右。大部分用户活跃到晚上7点左右,此后业务系统基本处于空闲状态。我们设置的备份策略为每天凌晨12点进行逻辑全备,备份大约耗时2小时,然后我们会进行一些日常的数据库清算操作。

    不幸的是,在星期一早上10点,系统崩溃了,导致数据磁盘损坏。我们唯一的选择就是从头开始,重新创建数据库,并使用最近的逻辑备份进行数据恢复。恢复数据库耗费了约3小时。在进行了一系列整理和基本功能测试后,应用程序在下午2点恢复正常。

    这里有两点需要注意:

    1. 该数据库从夜间的备份恢复。即,有10个小时的数据丢失。->丢失数据的多少,或者说能恢复到的时间点,对你来说有多重要?
    2. 4个小时的业务宕机时间。->可以多快恢复数据库并使业务可用?

    何为还原点目标(RPO,Recovery Point Objective)和恢复时间目标(RTO,Recovery Time Objective)?

    还原点目标(RPO)

    还原点目标是对于能够容忍的最大丢失数据量的度量。也用以衡量在最新数据库备份与故障发生之间的时间差。RPO用以决定PostgreSQL的备份频率。

    RPO很重要,因为在大部分场景下,当故障发生时,很有可能会造成数据丢失。即使数据备份是实时的,也有丢失数据的风险。而大部分业务系统会周期性备份数据,比如每小时一次、每天一次,更有甚者,每周一次。RPO衡量了当故障发生时,你能承担的数据丢失量。

    例如,假设在每天的半夜备份数据库,而在某天的早晨八点,故障发生了。那么,你就会丢失八个小时的数据。如果RPO设定为24小时或更长时间,那么还能接受;但是如果RPO设定为4小时或更少,那么这就是不能接受的了。

    恢复时间目标(RTO)

    恢复时间目标是用以衡量在故障后需要多快速恢复业务(应用程序及数据库)和服务的指标,用以维持业务的持续性。

    RTO用以衡量,在故障发生之后恢复正常业务所需的时间。例如,RTO设定为24小时,则意味着,企业可以在没有正常数据及基础架构可用的情况下,在该时间段维持运转。但是如果数据及其基础架构在24小时内未恢复正常,那么企业将遭受无可挽回的损失。

    需要根据设置的目标(RPO及RTO)决定备份策略。请谨记,PostgreSQL备份策略包含以下方面:

    1. 备份方式(在线,离线,逻辑);
    2. 备份频率(每周,每天,每小时);

    在上例中,若想实现最小数据丢失,可采用以下备份策略:

    1. 启用归档(保存WAL到安全的路径);
    2. 在线全备(PITR)+增量/归档备份:
      1. 每周全备;
      2. 每天半夜进行增量备份;

    然后在故障发生时,就可以进行时间点还原,即,通过使用全备还原数据库,然后使用增量备份(归档的WAL文件)恢复到最近的时间点。

    最常用的PostgreSQL备份策略(视具体情况而定)

    基于多年的数据库管理经验,我发现仅仅根据数据库的大小而制定备份策略是不明智的。在某些场景下,同时结合在线备份和逻辑备份(pg_dump/pg_dumpall)是一个不错的策略,但是,需要同时将数据的类型以及在灾难故障情况下能够容忍的数据丢失考虑在内。

    1. 关键数据库以及生产数据库,每周在线备份+每天的增量备份;
    2. 非关键或开发数据库,每周或每两周一次逻辑备份;

    其他备份方法

    其中一种较为常用的备份方法,是在将数据库更改到备份模式后,使用pg_basebackup进行在线备份或者进行文件系统级别的备份(直接拷贝整个数据文件目录)。另外,如果对磁盘使用存储管理,那么可以使用磁盘级别的快照进行备份。且对于大数据库(超过2TB)来说,卷级别的快照会更快、更有用。

    如何缩减RPO及RTO?

    现在,我们对于RPO及RTO的用法及其对于业务系统的重要性有了较为初步的了解。以下为在数据库级别缩减RPO及RTO的最佳实践:

    1. 具有自动故障转移的同步复制:如果无法承受数据丢失(关键业务、银行业、金融组织),那么使用PostgreSQL的同步复制绝对能够提供帮助,它能确保在备节点有业务库所有已提交的数据备份(取决于具体的同步模式)。一旦故障发生,可以自动或者手动切换到备端,以显著缩短RTO及RPO。可以通过设置应用程序等待提交成功后再结束事务,以确保没有数据丢失。不过,PostgreSQL的这种同步复制的设置可能会增加应用程序性能的额外开销。
    2. 具有自动故障转移的异步复制:流复制默认复制方式为异步复制,此种方式下,主库已提交事务与该事务在备库执行之间会有一段较小的延迟。该延迟大小取决于压力/事务以及带宽,但该延时比基于文件的日志传输要小很多。使用流复制时,无需设置archive_timeout来减小数据丢失窗口。我们还见过客户使用具有24小时延迟的备库以应对某些特殊的恢复场景,比如用户不小心删掉了一张表,那么延迟的备库可以用来恢复该表(需要在24小时内发现该意外行为)。

    1. 考虑设置灾难恢复站点:PostgreSQL可通过使用WAL在另一区域设置灾难恢复站点。对于当整个数据中心不可用或无法访问的任何灾难故障情况下,确保在另一个区域或数据中心拥有最新的数据库副本,至关重要。您可能会或可能无法承受数据丢失(RPO),不过即使数据中心完全丢失,也能缩短RTO时间。

    总结

    一个备份策略成功的关键是理解终端用户以及业务。这可以帮助你明白,当灾难故障发生的时候,你的数据有多重要以及需要多快恢复业务系统正常。这能帮助我们确定RTO及RPO目标。并据此找到正确的解决方案(无论是备份、主备或任何灾难恢复策略),且确保进行充分的可用性测试并最终进行部署实施。

    展开全文
  • SQL数据库备份恢复策略在教学管理系统中的应用.pdf
  • 但数据一旦丢失,造成的损失将不可挽回,程序发布到生产后,数据的备份便显得尤为重要,由于不一定所有的服务均有资金完成高级的备份如RAC和DG,在我们只有一台数据库服务器的,暂时采取最简单的备份策略,export出...
  • windows上oracle数据库rman自动备份策略

    热门讨论 2011-12-30 11:52:38
    windows系统下面oracle数据库使用RMAN工具执行增量备份, 应用任务计划程序定时执行脚本。
  • 主要给大家介绍了关于SQL Server数据库设置自动备份策略的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用sql server具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
  • 高校信息化管理系统中Oracle数据库备份策略——以北京理工大学珠海学院为例.pdf
  • 图书馆系统中Oracle数据库备份与恢复策略.pdf
  • 医院信息系统中Oracle数据库备份与恢复策略.pdf
  •  摘 要 恢复丢失的数据库文件在很大程度上取决于所采用的备份策略。本文从恢复的灵活性出发,对Oracle8数据库的备份及恢复策略进行了探讨,并给出了Windows 2000环境下使备份过程自动化的脚本文件的项目开发实例...
  • 谈图书馆系统中Oracle数据库备份方法及策略.pdf
  • 基于Oracle数据库的医院信息系统数据备份与恢复策略.pdf
  • 基于Oracle数据库的校园一卡通系统数据备份和恢复策略.pdf
  • 对于数据库数据的安 全问题,数据库管理员可以参考有关系统双机热备份功能以及数据库备份和恢复的资料。 一、组和安全性: 在操作系统下建立用户组也是保证数据库安全性的一种有效方法。Oracle程序为了安全性目的...
  • 进行详细oracle数据库的备份和恢复策略讲解,方便大家进行数据库备份恢复工作。
  • mysql数据库备份策略和方法 在数据库表丢失或损坏的情况下,备份你的数据库是很重要的。如果发生系统崩溃,你肯定想能 够将你的表尽可能丢失最少的
  • 达梦数据库备份方法总结学习

    千次阅读 2021-09-24 16:20:59
    支持故障恢复的技术主要是日志,日志以一种安全的方式记录数据库系统变更的历史信息,一旦系统出现故障,数据库系统可以根据日志将系统恢复至故障发生前的某个时刻。数据库系统的日志分为两种类型:一是REDO日志,在...

    数据库归档
    数据库系统在运行过程中可能会发生一些故障。造成故障的原因多种多样,包括磁盘崩溃、电源故障、软件错误,甚至人为破坏。数据库系统必须保证即使发生故障,也可以保障数据的完整性和一致性。
    支持故障恢复的技术主要是日志,日志以一种安全的方式记录数据库系统变更的历史信息,一旦系统出现故障,数据库系统可以根据日志将系统恢复至故障发生前的某个时刻。数据库系统的日志分为两种类型:一是REDO日志,在数据被修改后记录它的新值;另一种是UNDO 日志,在数据被修改前记录它的旧值。
    因此,当服务器处于归档模式时,如果数据库发生故障,通过备份文件和归档日志可以恢复到指定时间点。
    在数据库部署时,一定要开启归档!

    查看归档是否开启的方法时,可以执行语句查询

    SELECT * FROM V$DATABASE;
    

    在这里插入图片描述
    其中,归档方法有:
    1、联机归档

    ./disql
    ALTER DATABASE MOUNT;
    ALTER DATABASE ARCHIVELOG;
    ALTER DATABASE OPEN;
    

    在这里插入图片描述
    2、手动配置归档文件
    ① 关闭数据库实例

    cd /home/dmdbms/dmdbms/bin
    ./DmServiceDMSERVER stop
    

    ② 编辑 dmarch.ini 文件,保存在 dm.ini 所在的目录。

    cd /data/dmdbms/DAMENG
    

    #dmarch.ini 文件内容如下:

    [ARCHIVE_LOCAL1]
    ARCH_TYPE = LOCAL 
    ARCH_DEST = /data/arch
    ARCH_FILE_SIZE = 1024
    ARCH_SPACE_LIMIT = 2048
    

    #编辑 dm.ini 文件,设置参数 ARCH_INI=1,保存。
    #启动数据库实例

    cd /data/dmdbms/dmdbms/bin
    ./DmServiceDMSERVER start
    

    在这里插入图片描述
    在这里插入图片描述
    ③通过管理工具进行配置
    (1)打开达梦数据库管理工具,连接到实例
    (2)右键连接,选择“管理服务器”-“系统管理”,选择“配置”状态,点击转换;
    在这里插入图片描述
    (3)选择“归档配置”,归档模式选择“归档”,点击“+”,配置归档目标,归档类型,文件大小,空间限制大小等信息;
    在这里插入图片描述
    (4)选择“系统管理”,选择“打开”状态,点击转换,点击“确定”,配置归档完成。

    备份策略
    1、脱机备份、脱机还原

    创建完全备份:

    RMAN>BACKUP DATABASE '/data/dmdbms/DAMENG/dm.ini' FULL BACKUPSET '/data/dmdbms/backup/full_bak_20210917';
    

    在这里插入图片描述
    在这里插入图片描述
    创建增量备份:

    RMAN>BACKUP DATABASE '/data/dmdbms/DAMENG/dm.ini' INCREMENT WITH BACKUPDIR '/data/dmdbms/' BACKUPSET '/data/dmdbms/backup/full_bak_20210917';
    

    在这里插入图片描述
    2、联机备份、脱机还原
    ① SQL备份

    cd /home/dmdba/dmdbms/bin/
    ./disql
    SQL> BACKUP DATABASE BACKUPSET '/data/dmdbms/backup/full_bak_2021091701’;
    

    ② RMAN备份

    RMAN>BACKUP DATABASE FULL BACKUPSET'/data/dmdbms/backup/full_bak_20210917';
    

    RMAN备份工具下,热备区别冷备在于不需要指定dm.ini
    数据库还原和恢复

    1. 准备目标库。还原目标库可以是已经存在的数据库,也可使用dminit工具初始化一个新库。
      2)校验待还原备份集的合法性
    RMAN> check backupset '/data/dmdbms/backup/full_bak_20210917';
    

    在这里插入图片描述

    1. 还原数据库
    RMAN>RESTORE DATABASE '/data/dmdbms/DAMENG/dm.ini' FROM BACKUPSET '/data/dmdbms/backup/full_bak_20210917';
    

    在这里插入图片描述
    数据库恢复

    RMAN> RECOVER DATABASE '/data/dmdbms/DAMENG/dm.ini' FROM BACKUPSET '/data/dmdbms/backup/full_bak_20210917';
    

    在这里插入图片描述
    5)更新DB_MAGIC恢复

    RMAN>RECOVER DATABASE '/data/dmdbms/DAMENG/dm.ini' UPDATE DB_MAGIC;
    

    在这里插入图片描述

    更多资讯请上达梦技术社区了解: https://eco.dameng.com

    展开全文
  • 研究了关于检测点的备份策略,系统每次完成工作的时间是随机的,在定期时间进行检测或者在完成工作以后的随机时间进行检测,当系统发生故障时备份操作开始执行直到最近一次检测点。利用几何过程理论求出了系统从开始...
  • Oracle数据库安全策略

    2020-09-11 14:33:55
    Oracle数据库安全策略
  • 通过定时任务实现数据库文件自动备份压缩,对备份文件做定期删除。 使用教程:http://blog.csdn.net/chen_gp_x/article/details/79298983
  • 基于数据库维护计划的数据库备份方案 作者:魏忠强 来源:《中国科技博览》2014年第03期 摘要:为了保证数据库数据的安全,要定期对数据库的数据进行备份,对于备 份的策略要依具体情况而定,对数据库备份的原因主要...
  • 数据库备份与恢复技术

    千次阅读 2022-03-19 23:14:26
    数据库备份有多种分类方式。按备份的实现方式,可分为物理备份和逻辑备份,其中物理备份又分为冷备份和热备份;按备份的数据量分,则可分为完全备份、增量备份、差异备份。 一、按备份实现方式划分 1、冷备份 2、热...

    日志原理目前还没有看到谁说的比较清楚的。

    数据库运行过程中,安全事故的发生难以避免。其中有可能是人为因素,也有可能是硬件设备故障,甚至是自然灾难。因此,数据库除了安全性技术防范,还需要有备份与恢复技术来进一步保障数据的安全,当数据被破坏以后,可以尽可能的将数据库调整到破坏前的状态。

    数据库备份有多种分类方式。按备份的实现方式,可分为物理备份和逻辑备份,其中物理备份又分为冷备份和热备份;按备份的数据量分,则可分为完全备份、增量备份、差异备份。
    在这里插入图片描述

    一、按备份实现方式划分

    1、物理备份
    在操作系统里直接备份数据库的数据文件。我有个疑问,直接备份数据库的数据文件,恢复的时候,数据库能识别这些文件吗?能顺利加载它们吗?

    1)冷备份
    也称为静态备份。先将数据库停止、关闭,然后把数据库的文件全部复制下来,可能就是整个数据库吧,包括数据库本身,以及各种数据文件。通常,我会将数据文件与数据库本身分开存放,复制起来工作量不小。

    但是,据说冷备份是数据库备份中最快和最安全的方法。

    2)热备份
    也称为动态备份。利用备份软件,在数据库正常运行的状态下,将数据库中的数据文件备份出来。直接拷贝是不行的,数据文件处于锁定状态,要利用专用备份软件。

    3)冷备份 VS 热备份
    在这里插入图片描述
    简单来说,冷备份快速,但要停止数据库;热备份不用停止数据库,但一旦失败,后果严重,备份不成不说,估计整个数据库都完蛋。

    2、逻辑备份
    逻辑备份是指利用DBMS自带的工具软件备份和恢复数据库。比如,oracle的export、import(oracle 10g以前是exp、imp)。

    逻辑备份可以按表、表空间、用户和全库4个层次备份和恢复数据。但如果数据库非常大,这种备份方式速度很慢,耗时很长,一般采用物理备份。

    二、按备份数据量划分

    1、完全备份
    整个数据库中的数据进行备份。

    2、增量备份
    备份上一次备份(包括完全备份、增量备份和差异备份)后发生变化的数据。

    3、差异备份
    备份上一次完全备份后发生变化的所有数据

    三、备份文件的存放

    数据备份好了之后并非万事大吉,备份文件不应该只放在服务器本机,还要异机存放、异地存放,避免团灭。

    四、日志文件

    这里说的日志文件指的是记录事务日志的文件。对于任何一个事务,日志都有非常全面的记录,根据这些记录可以将数据文件恢复成事务前的状态。从事务动作开始,事务日志就处于记录状态,事务执行过程中对数据库的任何操作都记录在内,直到用户提交或回滚后才结束记录。

    DBMS的原则是先写日志再修改数据,数据库如果中途挂掉,重启或恢复时,可以根据日志文件结合检查点,按需要重放,以保持数据的一致性。

    不同数据库机制不同,按照不同日志文件分类,有的日志文件会循环使用,而有的日志文件则会越来越大。我记得SQL SERVER里,做一次完全备份就可以截断日志文件,将备份前的日志清掉,日志文件得以收缩。oracle好像也有类似机制。而且,日志记录模式,有详细有简洁,作为选项,视乎需要设置。

    五、数据恢复

    将数据库从错误状态恢复到某一个已知的正确状态的功能,称为数据库的恢复。数据恢复的思想就是冗余,而建立冗余的方法有数据备份和日志文件等。根据故障的不同类型,采用不同的恢复策略:

    1、事务故障恢复
    事务故障的恢复由系统自动完成,无须DBA参与。具体步骤为:

    反向扫描日志文件,对事务的更新操作执行逆操作,直到读取事务开始标记,事务故障恢复完成。(但也有数据库更新数据时,是先更改内存数据,积累到一定量或时间才写入持久化介质,而日志文件是事务提交则写入磁盘,因此事务故障恢复不一定是执行逆操作,也可能是根据日志的记录重放操作?)

    这里的事务故障恢复,应该是指不重启数据库的情况。

    2、系统故障恢复
    系统故障恢复在系统重启时完成,同样不需要用户干预。步骤如下:

    1)正向扫描日志文件,找出故障发生前已经提交的事务,记入重做(Redo)队列;同时找出故障发生前尚未完成的事务,记入撤销(Undo)队列。

    2)反向扫描日志文件,对撤销队列的事务中的更新操作执行逆操作

    3)正向扫描日志文件,对重做队列的事务中的更新操作执行重放操作

    3、截止故障与病毒破坏的恢复
    步骤如下:

    1)载入最后的备份文件,将数据库恢复到最近一次备份时的状态。

    2)从故障点开始反向扫描日志文件,找出已提交事务标识,并记入Redo队列

    3)从起始点(即最后备份时刻)正向扫描日志文件,将Redo队列的事务重放

    4、有检查点的恢复
    1)找出检查点建立时所有正在执行的事务

    2)未提交的事务做撤销处理

    3)已提交的事务重做

    检查点类似于一个里程碑。建立检查点的时候,DBMS会将内存中的数据持久化到磁盘里。通常,为提高性能,DBMS都是先修改内存里的数据,积攒到一定量才写入磁盘;而日志倒是事务提交时就马上写入磁盘。建立检查点的好处,就是故障恢复的时候,不用读太多的日志文件,做大量的Redo这种重复操作,只从最后的检查点开始就好。

    想想,现在吹得很火的DevOps,其中之一就是持续集成,即我们要经常地、至少每天提交一次代码,否则几天才提交一次,冲突的几率就很大了。数据库检查点也类似,经常性地持久化数据到磁盘。的确是个里程碑。

    展开全文
  • 数据库备份基本策略

    千次阅读 2013-05-07 11:34:33
    备份策略指确定需备份的内容、备份时间及备份方式。各个单位要根据自己的实际情况来制定不同的备份策略。目前被采用最多的备份策略主要有以下三种。 1、完全备份(full backup)  天天对自己的系统进行完全...
  • 怎样在Linux系统备份Oracle数据库

    千次阅读 2021-05-04 04:42:59
    在Linux中Oracle数据库备份的方法有很多,就像mysql一样可以使用不同方法进行备份oracle数据库先来介绍一些不使用脚本我们直接使用命令备份与还原oracle数据库Oracle数据备份:步骤 1 备份用户数据。1.使用linux系统...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 116,761
精华内容 46,704
关键字:

关于系统数据库的备份策略