- 综合排序
- 最热优先
- 最新优先
- 来自专栏iSharkFly
Confluence 6 站点备份和恢复 原
Atlassian 推荐针对生产环境中安装使用的 Confluence 使用原始数据库工具备份策略。 在默认的情况下，Confluence 每天都会备份所有数据和附件到 XML 文件备份中。 这些文件被称为 XML 站点备份，同时这些文件存储在 Confluence home 目录中的 backups 目录下面。可选的，你也可以手动创建一个 XML 站点的备份。 这种备份方式针对中小数据量的 Confluence 可以进行使用。这种备份方式针对有很多页面和附件的时候就变得不适用了（请查看下面）。 但是针对有大量页面的 Confluence 安装实例，这种备份方式就会变得非常缓慢，并且还会大量占用磁盘存储空间。 注意：插件是不会备份到 XML 的备份中的。 当你从 XML 的备份中重新导入到新的 Confluence 站点中的话，你需要为你的站点重新安装所有 Confluence 没有捆绑在一起的插件（插件使用的数据表也不会备份到 XML 文件中）。
78330发布于 2019-01-31 - 来自专栏iSharkFly
Confluence 6 如何备份和恢复 原
如何备份 有关备份你数据库使用的命令与你使用的具体数据库有关，例如针对 PostgreSQL 数据库，备份命令为 pg_dump dbname > outfile。 你应该针对你使用的数据库不同而参考数据库提供的备份文档。 如何恢复 文档 Migrating Confluence Between Servers 提供了有关使用备份进行回复应该使用的技术方案。
93930发布于 2019-01-31 - 来自专栏Laoqi's Linux运维专列
innobackupex备份恢复+增量备份与恢复
protected]03 backup]# innobackupex --defaults-file=/etc/my.cnf --copy-back ./2017-08-23_21-23-46/ 即可恢复咱们的备份到 //创建一个db123库 [[email protected]03 ~]# mysql -uroot -pzhangduanya db123 < /tmp/mysqlbak.sql //把之前备份的数据恢复得到 ---- 四、增量备份的恢复 4.1 为了还原真实性，我模拟删除数据库，并且停掉mysql，利用咱们已经备份的数据去恢复它。 4.7 然后开始恢复！ [[email protected]03 ~]# ls -ld /data/mysql drwxr-xr-x. 2 root root 6 Aug 24 23:50 /data/mysql [[email
13.4K100发布于 2018-05-09 - 来自专栏iSharkFly
Confluence 6 从其他备份中恢复数据
一般来说，Confluence 数据库可以从 Administration Console 或者 Confluence Setup Wizard 中进行恢复。 如果你在恢复压缩的 XML 备份的时候遇到了问题，你还是可以对整个站点进行恢复的，如果你能提供下面 2 个备份的话： 一个有关 home 目录的所有备份。 一个有关你数据库的备份（如果你使用的是外部数据库的话）。 有关恢复备份的方法基于你使用的是内部数据库还是外部数据库会有些不同。 外部数据库 如果你使用的是外部数据库，你需要进行下面的操作： 为你的 Home 目录和数据库准备备份（备份文件中最好添加备份备份的时间和日期）。 https://www.cwiki.us/display/CONF6ZH/Restoring+Data+from+other+Backups
1.1K30发布于 2019-01-31 - 来自专栏iSharkFly
Confluence 6 其他需要备份和恢复的地方
XML 备份被描述用于在 Confluence 备份使用的其他方法，例如升级和移动服务器。使用上面描述的备份和恢复方法也适用这些地方。 我们的 upgrade guide 不要求使用一个 XML 备份（尽管早期的 Confluence 和 Jira 升级向导需要使用 XML 备份数据）。 我们的 migrate server procedure– 被用来设置一个测试服务器，你可以可以使用 SQL 的备份。 database migration 针对小的数据集使用 XML 备份。 大数据量的备份要求使用第三方的数据库整合工具。 注意： Confluence 自带的 XML 方式导出方法并不适用于备份和整合大数据集。 这里有一些第三方的数据库工具你可以使用能够帮助你对大数据集进行备份和整合。
53610发布于 2019-01-31 - 来自专栏linux运维
备份恢复问题：备份文件恢复失败，数据无法恢复
排查恢复失败的原因在解决问题之前，需要明确恢复失败的具体原因。以下是一些常见原因及其排查方法：（1）备份文件损坏原因：传输中断、磁盘故障或未正确校验。 确保所有关键数据都包含在备份中。（3）恢复过程错误原因：恢复命令或工具使用不当。排查方法：确保使用的恢复工具与备份工具一致。检查恢复路径和权限是否正确。2. 优化备份生成过程确保备份文件本身是完整且可靠的，这是成功恢复的前提。（1）使用可靠的备份工具选择支持断点续传、校验和错误处理的备份工具。例如：rsync：支持增量备份和断点续传。 （1）恢复文件系统备份# 示例：从 tar 文件恢复数据 tar -xzf /backup/full_backup_20250207.tar.gz -C /restore/directory（2）恢复数据库备份 /log/restore_test.log fi} restore_test6.
3.1K10编辑于 2025-02-07 - 来自专栏iSharkFly
Confluence 6 用户提交的备份和恢复脚本
删除老的备份 —— Windows 的 Wscript 脚本 这个脚本将会检查备份文件然后删除他们（必要的话），下面的代码可能需要一些编辑。 —— Linux Basic Bash Script Old 的 XML 备份可以通过每天晚上或者每周的自动运行脚本进行删除。 你也可以在 cron 中设置相似的脚本： ls -t <path to your backup dir>/* | tail -n +6 | xargs -i rm {} 或者，使用 tail 命令，如果你的系统不支持标准格式的话 ： ls -t <path to your backup dir>/* | tail +6 | xargs -i rm {} Del 删除老的备份 —— 高级 Linux Bash Script Old —— Linux Basic Bash Script 这个将会备份 MySQL 数据库和 Confluence 的 Home 目录。
86920发布于 2019-01-31 - 来自专栏JiekeXu之路
MongoDB 备份恢复
作者 | JiekeXu大家好，我是JiekeXu,很高兴又和大家见面了,今天和大家一起来聊聊MongoDB 备份恢复去年中旬安装过 MongoDB，没有怎么实操，本次将备份相关的操作做一个总结，后续有用到的地方可以回来查看 mongodump 和 mongorestore 是用于备份和恢复小型 MongoDB 的简单而高效的工具，但不适合捕获大型系统的备份。 要恢复使用 --oplog 创建的备份，请将 mongorestore 与 --oplogReplay 选项结合使用。 会有较小的性能影响--oplogReplay # 恢复备份数据并将 mongodump 执行期间的操作(记录在导出的日志)恢复。 Can also use --host hostname:port --ipv6 enable IPv6 support (disabled by default
2.3K31编辑于 2022-07-20 - 来自专栏小黑博客
MySQL备份恢复
可以本地、可以远程备份。 注意： 一般情况下，恢复需要耗费的时间是备份耗费时间的3-5倍。 如果只是部分损坏，建议找一个应急库进行恢复 全备恢复 日志截取并恢复 恢复后数据校验 （业务测试部门验证） 立即备份（停机冷备） 恢复架构系统 撤维护页，恢复业务 环境搭建 mysql> create 拷贝的同时，会将备份期间的redo进行备份 恢复逻辑 ： 模拟了InnoDB Crash Recovery 功能，需要要将备份进行处理（前滚和回滚）后才能恢复 安装yum 源 [root@cs ~]# （2）增量备份无法单独恢复。必须基于全备进行恢复。 （3）所有增量必须要按顺序合并到全备中。 测试库进行备份恢复及日志恢复 5. 应用进行测试无误，开启业务 6.
14.5K21编辑于 2022-12-28 - 来自专栏全栈程序员必看
ORACLE备份恢复
目录 一、关于备份与恢复 二、逻辑备份（expdp和impdp） 三、物理备份 四、数据库日常备份计划及脚本参考 一、关于备份与恢复 1、备份定义 备份就是把数据库复制到转储设备的过程。 介质恢复又分为完全恢复和不完全恢复 完全恢复：将数据库恢复到数据库失败时的状态。这种恢复是通过装载数据库备份并应用全部的重做日志做到的。 不完全恢复：将数据库恢复到数据库失败前的某一时刻的状态。 RMAN> list backup; 查看复制文件 RMAN> list copy 6、验证备份 RMAN> validate backupset 3; 这里说明一下，3这个数字代表的是备份集的编号 .星期一晚上：增量备份 3.星期二晚上：增量备份 4.星期三晚上：累积备份 5.星期四晚上：增量备份 6.星期五晚上：增量备份 7.星期六晚上：增量备份 如果星期二需要恢复的话，只需要1+2 如果星期四需要恢复的话，只需要1+4 如果星期五需要恢复的话，只需要1+4+5 如果星期六需要恢复的话，只需要1+4+5+6 如果需要自动备份，可使用备份脚本+crontab的方式执行 执行脚本命令
3.6K21编辑于 2022-09-13 - 来自专栏ops技术分享
Jira备份恢复
一.备份 1.管理员账号登录Jira，点击右上角的”系统”-“导入导出”-“备份系统”，Jira默认会打开自动备份的功能，备份路径为/var/atlassian/application-data/jira /export；入如果没有打开，也可以手动进行备份，如下，可以自定义备份的文件名。 点击右上角的”系统”-“高级”-“附件”就可以看到Jira附件的设置 二.恢复 1.点击右上角的”系统”-“导入导出”-“恢复数据”，将备份到/var/atlassian/application-data /jira/export里的数据拷贝到 /var/atlassian/application-data/jira/import路径下进行恢复即可！ 需要注意：Jira和confluence的mysql数据库的数据也要定时进行备份。写个shell备份脚本，结合crontab进行每天定时备份。
2K10发布于 2021-07-05 - 来自专栏ops技术分享
gitlab 备份&恢复
Gitlab 成功运行起来之后，最终的事情就是定期的备份，遇到问题后的还原。 备份配置 默认 Gitlab 的备份文件会创建在/var/opt/gitlab/backups文件夹中，格式为时间戳_日期_版本号_gitlab_backup.tar，例如：1515031353_2018 手动备份 命令：gitlab-backup create For GitLab 12.1 and earlier, use gitlab-rake gitlab:backup:create 会在命令执行的时间点 ，在你配置的文件夹或者默认文件夹创建一个备份文件。 自动备份 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1 备份恢复 First make sure your backup tar file
2.1K30发布于 2021-06-04 - 来自专栏xiaozhangStu
索引恢复备份
索引恢复备份 MySQL的事务处理 事务就是将一组SQL语句放在同一批次内去执行 如果一个SQL语句出错，则该批次内的所有SQL都将被取消执行 事务必须具备以下四个属性 原子性（Atomicity） 一致性 5、possible_keys：列指出MySQL能使用哪个索引在该表中找到行 6、key：显示MySQL实际决定使用的键（索引）。 ORDER BY 子句中经常使用的字段 字段的值是多个（例如性别字段则不适合） 字段内容不是经常变化的 经常变化的字段，添加索引反而降低性能 不宜过多添加索引 每添加一条索引都会占用磁盘空间 MySQL的备份与恢复
92720编辑于 2023-05-04 - 来自专栏惨绿少年
Mysql 备份恢复与xtrabackup备份
表数据 6.备份完成。 3）能够基于压缩等功能节约磁盘空间和流量 4）自动备份校验 5）还原速度快 6）可以流传将备份传输到另外一台机器上 x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm yum -y install percona-xtrabackup-24-2.4.4-1.el6. 5、导出删除的表zjs_base，恢复到生产库，验证数据可用性、完整性。 6、启动应用连接数据库。 确定恢复所需时间 恢复窗口要多长？----> 预计3小时 和你恢复+验证+意外情况有关。 业务停多长时间？----> 6小时？或者更多？
17.2K30发布于 2019-05-24 - 来自专栏翻译社
6个虚拟机备份和恢复的最佳实践
永远不要将虚拟机快照用作主要的备份手段，尽管从短期的角度来看它们是一种令人满意的备份方法。要了解更多有关为什么不应将快照用作灾难恢复计划的信息，请单击此处。 3.在虚拟化层上备份虚拟机 我们在备份传统的物理服务器时，习惯上在客户机操作系统上安装备份代理程序。当备份服务器要启动备份操作时，备份服务器会联系该代理来完成备份。 4.将备份复制到辅助位置 企业IT环境不应将所有备份数据放在一个位置。至少要有一个备份数据副本不在现场，这样可以确保发生在实际生产地点的灾难不会让您在需要备份来恢复时空手而归。 如果他人拿到未加密的备份数据，则可以直接恢复备份，并可以利用备份中的敏感数据。加密备份消除了这种安全风险。 6.定期测试恢复软件 定期备份虚拟机只是第一步。 您一定不想当您需要从备份中还原您的虚拟机时才发现备份已经损坏。 定期在测试环境中测试您的恢复软件，来确保备份没有损坏。
2.3K60发布于 2018-01-08 - 来自专栏iSharkFly
Confluence 6 尝试从 XML 备份中恢复时解决错误
也有可能是你备份文件有问题，你需要找到你 XML 备份文件中违反数据库规定的记录修改这个记录后再创建一个新的 XML 备份： 在实例开始恢复的时候，请按照下面的指南来禁用批量更新（针对简单的问题解决）， 尝试另外一次恢复。 当你在恢复的时候失败了，检查你的日志文件找到不能用 XML 转换为记录的地方。 进入到你服务器创建的备份文件中，你应该有你数据库使用的备份。如果你没有这个的话，使用DBA 数据库管理工具创建一个数据库备份。 一旦上面的修改完成了，重新创建 XML 备份。 导入备份到新的版本中。
1.6K20发布于 2019-01-31 - 来自专栏云计算
6个虚拟机备份和恢复的最佳实践
部署的备份应用可以向VMkernel查询被更改的盘块信息，并且只对这些盘块进行备份，以此实现更快的增量备份。 快照不是备份 快照并不复制虚拟机的数据。 在宿主机上进行备份 备份传统的物理机时，常见的做法是直接在操作系统上安装备份工具，在需要备份时，备份服务器就直接访问物理机。这样做在虚拟机中效率较低。 将备份保存在多个地点 企业级的IT环境不能接受只在一处保留备份的风险。在服务器部署地之外有至少一份备份可以确保在部署地点严重受灾时不会出现没有备份可用的情况。 更理想的情况是，次要的备份仓库应该放在现实中不同的两地或放在“云”上。这样，只要还能连接到备份仓库，就可以访问之前的备份。 加密备份 加密可以保证备份安全。 假如有人窃取了未加密的备份数据，从这一份备份还原出的数据中，可以获取到一些机密信息。加密备份则避免了这样的安全漏洞。 定期测试还原工具 做到定期备份虚拟机仅仅只是备份的第一步。
1.6K100发布于 2018-01-08 - 来自专栏Linux云运维
MySQL备份与恢复
MySQL备份与恢复 1、数据备份概述 备份是数据安全的最后一道防线，对于任何数据丢失的场景，备份虽然不一定能恢复百分之百的数据(取决于备份周期)，但至少能将损失降到最低。 ： 恢复点目标(RPO) 恢复点目标是指数据能恢复到什么程度 恢复时间目标(RTO) 恢复时间目标是指数据恢复需要多长时间 1.2 数据库备份分类 数据库备份方式分很多种，从物理与逻辑的角度来看，备份可分为 它比最初的完全备份小，因为只包含自上次完全备份以来所改变的数据库。它的优点是存储和恢复速度快。 增量备份：只有那些在上次完全备份或者增量备份后被修改的文件才会被备份。 数据库物理热备的备份工具，能够非常快速地备份与恢复mysql数据库，且支持在线热备份（备份时不影响数据读写）。 # 恢复阶段：准备备份，恢复之前需要准备备份 [root@localhost ~]#xtrabackup --prepare --target-dir=/backup/xtrabackup/ # 恢复数据
4.8K20编辑于 2022-08-23 - 来自专栏Man_Docker
mysql备份和恢复
备份数据库 innobackupex --defaults-file=/etc/my.cnf --user='xxx' --password='xxx' --slave-info --safe-slave-backup /database/backup 恢复数据库 第一个是对备份做两个操作： 1、应用备份期间的redo log 2、回滚备份完成时刻未提交的事务 /usr/bin/innobackupex --defaults-file =/etc/my.cnf --apply-log /database/backup/xxx 第二个是把备份文件移动到配置文件里配置的datadir（这个目录要保证为空）目录下 /usr/bin/innobackupex
2.5K20编辑于 2022-02-28 - 来自专栏电光石火
gitlab备份与恢复
1.备份数据 gitlab-rake gitlab:backup:create #执行命令备份数据库 这是会自动备份到backups这个目录下面的，备份文件前面的一串数字就是时间戳，还原时候回用到！ 2.使用scp命令把备份的数据拷贝到新的服务器上面去（我用的是免密传输） scp -r 1563788420_2019_07_22_10.4.2_gitlab_backup.tar root@192.168.1.1 :~ 3.到新服务器把刚才拷过来的备份文件放在backps目录下面： cp -rf /root/1563788420_2019_07_22_10.4.2_gitlab_backup.tar /var 1563788420_2019_07_22_10.4.2_gitlab_backup.tar (3)旧服务器的版本gitlab版本和新的服务器版本是不通的 解决方法，那就只能升级了，保持两个版本是一样的，在备份还原才行
1.9K10发布于 2019-12-07
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号