- 综合排序
- 最热优先
- 最新优先
- 来自专栏云数据库技术
使用 NineData 快速构建企业容灾备份
据美国航空监管机构报道，这次事故原因是数据库文件受损，可见企业容灾备份的重要性。 数据库为数据提供存取服务，担任着重要的角色，如果因服务器故障、程序 BUG、操作人员勿删、病毒感染、恶意删除等原因导致数据丢失或服务不可用，会对公司造成重大损失，所以构建企业容灾就是提高企业核心竞争力， 企业数据容灾备份方法按照不同的数据库备份方式，数据库备份可以分为完全备份、增量备份（又称差异备份）、事务日志备份、文件备份。完全备份备份整个数据库，恢复时恢复所有。 NineData 提供的备份功能，包括数据备份、结构备份、日志备份，具备全量和增量的备份能力，基于这些能力，可以快速、有效的帮助企业构建数据容灾备份能力。 小结通过这篇介绍，可以了解到如何使用 NineData 快速构建企业容灾备份。
1K50编辑于 2023-02-07 - 来自专栏IfDataBig
Hbase容灾与备份
一、前言 本文主要介绍 Hbase 常用的三种简单的容灾备份方案，即CopyTable、Export/Import、Snapshot。 Export 还支持指定导出数据的开始时间和结束时间，因此可以用于增量备份。
2K40编辑于 2022-07-27 - 来自专栏容灾备份那些事
高校容灾备份方案 2.0
容灾备份方案 2.0 需要建设一套实时性更强的容灾备份系统，以实现业务系统数据实时备份保护及应用级业务接管，以符合下图的数据级向应用级容灾备份的趋势。 △容灾级别与能力 三、容灾备份方案 2.0 的创新应用 容灾备份方案 1.0，有基于硬件存储层架构，也有基于应用层架构。基于硬件存储层方案，建设和运维成本比较高。 英方软件基于超低时延的数据复制技术，针对云和大数据环境下行业对容灾备份的新要求，提出了容灾备份方案 2.0。 △容灾备份方案 2.0 2.0 方案覆盖数据库系统故障、应用系统故障、单机单点故障、逻辑错误&病毒攻击、自然灾害等场景，满足高校在数据库双活、云灾备、容灾秒级接管、数据持续保护等容灾备份需求，具备了多层次 以最简单的方式，帮助企业完成操作系统、文件、数据库和应用等所有数据的整体保护和验证，部署和操作也更加简单。
2.2K30发布于 2021-03-02 灾备知识总结：容灾与备份区别、灾备技术、容灾体系规划
本文通过浅显易懂的语言，系统梳理容灾、备份、灾难恢复等核心概念，结合中科热备等前沿技术方案，为企业构建多层级灾备体系提供理论与实践指导。一、核心概念解析1. 灾难恢复（Disaster Recovery）阶段定位：灾难发生后的系统重建与容灾关系：现代容灾系统集成恢复功能二、容灾与备份的协同关系1. 功能互补性2. 典型故障应对案例1：数据库误删操作容灾系统同步删除→需从备份恢复案例2：机房级火灾容灾系统接管业务→备份用于数据追溯三、企业灾备体系规划策略1. 风险评估矩阵2. 典型建设路径初级阶段：本地备份+双机热备（中科热备HA方案）进阶阶段：同城双活+异地备份成熟阶段：多云容灾+区块链存证四、灾备技术体系详解1. 建议企业根据业务特性选择"备份+容灾+恢复"的三维防护策略，定期开展灾备演练，真正实现业务连续性保障。
68010编辑于 2025-09-16- 来自专栏ops技术分享
mysqldump备份容灾脚本（上）
一.备份脚本 环境需求 编辑/etc/my.cnf文件添加在[mysqld]版块下添加如下变量，添加后重启服务 #开启，并且可以将mysql-bin改为其它的日志名 log-bin=mysql-bin /xx.sh -uroot -p'123456'，使用前修改脚本进行变量配置 #过程：备份并刷新binlog，将最新的binlog文件名记录并整体压缩打包 #恢复：先进行全量备份，再对根据tim-binlog.txt }days "+%F";done)) #开始 /usr/bin/echo >> ${log_dir} /usr/bin/echo "time:$(date +%F-%H-%M-%S) info:开始全备份 -ne 0 ]];then /usr/bin/echo "time:$(date +%F-%H-%M-%S) error:备份失败" /usr/bin/echo "time:$(date +%F-% H-%M-%S) error:备份失败" >> ${log_dir} /usr/bin/cat /tmp/bak_error.txt #如果错误则显示错误信息 exit 1 else
1.4K00发布于 2021-06-09 - 来自专栏民工哥技术之路
灾备知识总结：容灾与备份区别、灾备技术、容灾体系规划
容灾系统在企业中给与数据安全系数相当高的保障，但是容灾系统倒是是什么，他们是什么意思？恐怕连正在使用容灾备份的网络管理人员都不能解释。本文用最浅显的语言给大家解释容灾备份到底是什么。 备份是数据高可用的最后一道防线，其目的是为了系统数据崩溃时能够恢复数据。 容灾不可少 那么建设了备份系统，是否就不需要容灾备份系统？ 如果是同步容灾，那容灾端同时就删除了；如果是异步容灾，那容灾端在数据异步复制的间隔内就会被删除。这时就需要从备份系统 中取出最新备份，来恢复被错误删除的信息。 规划企业安全保障体系考虑的因素 对于企业而言到底应该如何建设自己的灾备系统，是只建设备份系统、还是只建设容灾系统、还是需要二者同时建设、或者是分步骤的建设，谁先谁后等问题，主要根据业务的需求而定： （1 ）需要防范的灾难类型： 企业信息系统可能遇到的灾难类型及其发生的比例如下： 对于“人为错误”、“软件损坏和程序错误”加上“病毒”等这些都称为逻辑错误，占总故障的 56%，这些错误只能通过备份系统才能防范
13.3K21发布于 2021-01-12 - 来自专栏ops技术分享
mysqldump备份容灾脚本（下）
三.容灾测试 准备 按照第一步，环境需求中，将mysql开启binlog并重启，也可以设置全局变量，不用重启 vim /root/bin/mybak-all.sh，将全量脚本复制到其中，并 chmod+ cd /ops/bak 解开最近时间点的全量备份包，最近时间是2016-04-06 tar -xf mybak-all-2016-04-06-00-00.tar.gz 解压后可以看到 mybak-all 解压增量备份的文件夹 ，因为这2个脚本是先后执行的，所以不需要解压6号前的，只解压6号及以后的。 mybak-section-2016-04-06-00-00.tar.gz 解压后可以看到 mysql-bin.000008 和 mysql-bin.000009 2个binlog日志 恢复第二步：全备份恢复 mysql -uroot -p'123456' 检查表的条目数是否是3000条，因为在写入3000条后，mysqldmp全备刷新了一下binlog，这个最新的是14，而还没有写入任何东西时便执行增量备份了
1.7K20发布于 2021-06-11 - 来自专栏ops技术分享
mysqldump备份容灾脚本（中）
/xx.sh -uroot -p'123456'，将第一次增量备份后的binlog文件名写到/tmp/binlog-section中，若都没有，自动填写mysql-bin.000001 #过程：增量先刷新 binlog日志，再查询/tmp/binlog-section中记录的上一次备份中最新的binlog日志的值 # cp中间的binlog日志，并进行压缩。 再将备份中最新的binlog日志写入。 #恢复：先进行全量恢复，再根据全量备份附带的time-binlog.txt中的记录逐个恢复。当前最新的Binlog日志要去掉有问题的语句，例如drop等。 days "+%F";done)) #开始 /usr/bin/echo >> ${log_dir} /usr/bin/echo "time:$(date +%F-%H-%M-%S) info:开始增量备份 " >> ${log_dir} /usr/bin/echo >> ${log_dir} 二.备份策略 周日晚3点进行全量备份 周一到周六每天进行增量备份， 全量保存4周 增量保存近一周的每天数据 crontab
1.4K00发布于 2021-06-09 - 来自专栏云技术+云运维
容灾备份的7个等级
面对各种可能的灾难，企业需要方便、灵活地同步基于异构环境下驻留在不同数据库中的数据，这就需要建设一个对各种情况都可以抵御或者化解的本地和异地的容灾系统。 在这种容灾方案中，最常用的是备份管理软件加上磁带机，可以是手工加载磁带机或自动加载磁带机。它是所有容灾方案的基础，从个人用户到企业级用户都广泛采用了这种方案。其特点是用户投资较少，技术实现简单。 以前被许多进行关键业务生产的大企业所广泛采用，作为异地容灾的手段。目前，这一等级方案在许多中小网站和中小企业用户中采用较多。对于要求快速进行业务恢复和海量数据恢复的用户，这种方案是不能够被接受的。 4级：定时数据备份 第4级容灾方案是在第3级容灾方案的基础上，利用备份管理软件自动通过通信网络将部分关键数据定时备份至异地，并制定相应的灾难恢复计划。 采取这种容灾方式的用户主要是资金实力较为雄厚的大型企业和电信级企业。
6.4K30发布于 2019-10-29 - 来自专栏用户7621540的专栏
Redis数据备份，容灾恢复手段
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。 获取 redis 的安装目录可以使用 config get dir 命令 RDB优势与劣势 优势 适合大规模的数据恢复 对数据完整性和一致性要求不高 劣势 在一定间隔时间做一次备份，所以如果redis意外 正常恢复到内存中 ❝将有数据的aof文件复制一份保存到对应目录，目录路径可以通过config get dir命令获取，重新启动Redis就可以了 ❞ 异常恢复文件到内存中 ❝备份异常AOF文件，使用命令对文件进行修复
1.4K42发布于 2020-09-16 YashanDB容灾备份策略，保障企业关键数据安全无忧
针对这一普遍挑战，YashanDB提出了系统化的容灾备份策略，旨在保障企业关键数据安全无忧。 三、恢复机制与容灾支持YashanDB设计了多级恢复机制保障数据完整性：完整恢复：基于备份集进行全库恢复，并结合归档日志回放，确保恢复至指定时间点。 备份恢复机制与高可用架构协同，容灾过程支持主备切换（Switchover）和故障切换（Failover），通过redo日志复制和回放，确保数据切换和恢复的实时性和一致性。 合理规划备份存储介质，推荐使用企业级高可靠存储和远程灾备存储，防止单点故障。开启主备自动选主功能，实现故障自动切换，确保业务连续性。定期进行恢复演练，验证备份和恢复策略的有效性。 随着企业数据规模的不断增长和业务对数据可靠性的严格要求，构建高效、自动化的容灾备份体系，将成为数据库核心竞争力。
22610编辑于 2025-08-21- 来自专栏民工哥技术之路
Redis 备份、容灾及高可用实战
本文作者向大家介绍了一种Redis在非大集群分布式应用场景下的灾备解决方案。 当时的Redis都未采用分布式部署，采用单实例部署，并未考虑容灾方面的问题。 三，非分布式场景下Redis应用的备份与容灾 Redis主从复制现在应该是很普遍了。常用的主从复制架构有如下两种架构方案。 常用Redis主从复制 方案一 ? Redis主从复制优点与不足 优点 实现了对master数据的备份，一旦master出现故障，slave节点可以提升为新的master，顶替旧的master继续提供服务 实现读扩展。
1.5K20发布于 2020-09-16 - 来自专栏kubernetes中文社区
Redis 备份、容灾及高可用实战
当时的Redis都未采用分布式部署，采用单实例部署，并未考虑容灾方面的问题。 三，非分布式场景下Redis应用的备份与容灾 Redis主从复制现在应该是很普遍了。常用的主从复制架构有如下两种架构方案。 常用Redis主从复制 方案一 ? Redis主从复制优点与不足 优点 实现了对master数据的备份，一旦master出现故障，slave节点可以提升为新的master，顶替旧的master继续提供服务 实现读扩展。
1.4K20发布于 2019-07-28 - 来自专栏云计算之道
Ceph基于快照的备份容灾方案
Ceph的快照技术本来只是用来进行RBD或者Pool的回滚，但管理员可以利用快照进行Image的异地备份和容灾。 本文首先介绍Ceph的快照技术的使用方法，然后提出一种初级的异地备份方案，管理员可以以此为基础，创造更自动更智能的备份容灾方案。 image-diff> 导入增量镜像 a) 导入从创建到某一时刻的diff #rbd import-diff <image-diff> <pool-name/image-name> 基于快照的异地灾备方案 backup_dc 5) 将增量快照文件导入到backup_dc的image #rbd import-diff<image-snap-diff> <pool-bak/image-bak> 后续备份 ，管理员可以基于上述介绍编写自己的自动备份和恢复脚本，从而实现一个更完整更智能的两中心备份方案。
2.5K30编辑于 2022-06-13 - 来自专栏云计算之道
Ceph基于RBD Mirror的备份容灾
基于上述问题，Ceph从Jewel版本开始引入了RBD Mirror功能来解决Ceph存储在数据备份容灾方面的需求。 具体的写IO过程如下： 1）写请求首先把数据写入RBD Journal； 2）Journal写入成功后，RBD再把数据写入RBD image，并回复Client ACK响应； 3）备份集群中的rbd-mirror 发现主集群中的journal有更新，则从主集群中读取journal数据，写入备份集群的RBD image； 4）备份集群写入数据成功后，更新主集群的journal的元数据，表明该IO journal已经同步成功 ； 5）主集群定期检查并删除已经写入备份集群的journal数据。 基于该机制，可以方便地实现两个OpenStack和Ceph集群的数据备份和灾难恢复。
1.7K20编辑于 2022-06-13 - 来自专栏java思维导图
Redis 备份、容灾及高可用实战
当时的Redis都未采用分布式部署，采用单实例部署，并未考虑容灾方面的问题。 三，非分布式场景下Redis应用的备份与容灾 Redis主从复制现在应该是很普遍了。常用的主从复制架构有如下两种架构方案。 常用Redis主从复制 方案一 ? Redis主从复制优点与不足 优点 实现了对master数据的备份，一旦master出现故障，slave节点可以提升为新的master，顶替旧的master继续提供服务 实现读扩展。
1.1K10发布于 2019-07-19 YashanDB: 实现数据容灾备份的最佳实践
如何实现高效且可靠的数据容灾备份，成为数据库管理中的关键技术难题。容灾备份不仅关系到数据的完整性和安全性，也直接影响系统的恢复速度和运维复杂度。 因此，深入探讨基于YashanDB的容灾备份架构与最佳实践，对于提升数据库系统的业务连续性与数据安全具有重要意义。 YashanDB的容灾备份体系架构YashanDB提供了完备的容灾备份体系，涵盖多种部署形态和技术方案，以满足不同业务场景下的高可用需求。 容灾备份实施的技术建议合理规划部署形态：根据业务规模与性能需求，选择合适的单机、分布式或共享集群部署，确保容灾策略与系统架构高度协调。 未来，随着分布式数据库和云原生技术的发展，基于YashanDB的容灾体系将持续演进，满足更复杂、多样化的数据安全需求，助力企业构建稳健的数据基础设施。
20910编辑于 2025-10-18- 来自专栏开元说说
容灾系列（二）—— 企业借助云平台“一站式”容灾建设？
随着业务对持续性要求越来越高，云上不少企业对跨AZ或多地域的容灾建设有强烈的诉求。 当企业内部经过评估选定容灾建设整体方向，即同城双活；需要对方案进行验证，包括组件容灾能力建设，数据同步以及切换验证等。 通常对组件容灾能力建设和验证会花费大量时间，如果测试不符合预期，对之前调研、部署以及测试人力和时间成本带来较大耗费。因此借助云平台能力“一站式”提升系统容灾能力，助力企业降本增效。 云上核心产品拥有跨地域或者跨可用区容灾能力，减少企业对众多开源方案的依赖和研究，同时还能得到云产品的SLA稳定性的保障。 2）组件HA切换能力建设。 5）降低企业人力成本。云上通过控制台便捷的操作，一站式进行容灾建设；同时减少对社区开源软件维护以及二次开发的人力成本。
5K42发布于 2021-06-15 - 来自专栏腾讯云中间件专家服务
客户容灾案例—zookeeper容灾迁移方案
在至少有一个Leader存在的前提下，进行Zookeeper的在线增量、在线减量、在线迁移 在全过程中ZooKeeper不停止服务
2.3K51发布于 2021-07-26 - 来自专栏开元说说
容灾系列（六）——数据存储容灾建设
数据存储容灾建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢？ 企业通常使用数据存储产品主要为云硬盘（CBS）以及对象存储（CFS）。 列举一下几个场景： 场景一： CBS快照跨地域能力建设 当前云平台CBS数据可靠性的能力在地域粒度，对于公司核心数据要求多地域备份时，需要业务通过调用云API来实现；高可用能力建设核心思路： 1.定期快照复制新 针对读业务，解决是否有数据备份入口，供业务临时读。
4.5K73发布于 2021-11-18
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号