linux 文件备份命令

Linux备份命令详解

(2008-11-0807:58:34)

转载

标签：

杂谈

分类：LINUX学习

vdump的常用方式：

1). 对于文件需要在只读方式下备份的文件，建议进入单用户：

# init s 或

>>>boot–fl s

2). 对 *** 作系统各MOUNT点进行备份

3). # mount -a

# vdump -0uvf/dev/ntape/tape0_d1 /

# vdump -0uvf/dev/ntape/tape0_d1 /usr

# vdump -0uf/dev/ntape/tape0_d1 /var (如过var区是做为单独的文件子集也需要单独备份)

-f : 设备文件名 ( 比如 DDS tape driver)

-u : 更新/etc/vdumpdates，用于增量备份

- v: 备份内容详细列表

- 0 : 零级备份

/dev/ntape0_d1: 系统执行完毕后，磁带停止在当前位置，可继续往下备份

//usr/var : 各文件系统的MOUNT点

4). 其他说明

a、该命令方式对系统当前mounted的文件系统进行备份

b、备份级别说明

备份级别有0～9个级别，如果当前系统采用零级备份，当下一次采用5级备份时，系统仅将会对有变化的文件进行备份。

系统恢复常用命令--vrestore

恢复整个 *** 作系统各文件系统的内容：

1). 准备工作：

a. 准备一个可用的新硬盘，容量大小和原盘基本相符。

b. 准备一套与备份系统相同版本的安装光盘

2). 用 *** 作系统安装光盘启动到安装界面，调整新硬盘各分区大小后进入单用户。

* >>>bootdqa0 (dqa0 为SRM下的光驱设备号)

* 按正常安装步骤选着OK—》NEXT—》NEXT---》NEXT—NEXT---NEXT-CUSTOMIZEFILE SYSSTEM LAYOUT（调整分区大小）--》QUIT OR SHELL WINDOW。

* 注意：在调整新硬盘分区时一定要在引导块上选择ADVFS，并定义B区为SWAP

3). 创建 *** 作系统的各文件系统。（如系统新盘为 dsk0）

mkfdmn/dev/disk/dsk0a root_temp （创建文件系统域）

mkfset root_temproot （创建文件子集）

mkfdmn/dev/disk/dsk0g usr_temp

mkfset usr_temp usr

mkfset usr_temp var(条件：在原系统中VAR为单独的文件子集)

注：在高级文件系统创建过程中，域名只要不和原来冲突，命名是任意的。但对文件子集命名方面最好和原来一致。（以避免不必要的修改工作）

4). *** 作系统各文件系统的的恢复

#mount root_temp#root/mnt

#cd /mnt

#vrestore -xvf/dev/ntape/tape0_d1 (恢复该文件系统上所有数据)

#cd /

#umount /mnt

#mount usr_temp#usr/mnt

#cd /mnt

#vrestore -xvf/dev/ntape/tape0_d1

#cd /

#umount /mnt

#mount usr_temp#var/mnt （条件：VAR为单独的文件子集）

#cd /mnt

#vrestore -xvf/dev/ntape/tape0_d1

-f: 设备文件名

-x: 恢复磁带当前备份数据段上的所有数据

- v: 备份内容详细列表

5). 如果恢复硬盘与备份盘在系统中设备名的不同（如：备份盘为dsk0,恢复盘为dsk1）需要做以下修改：

#mount root_temp#root/mnt

#cd /mnt/etc/fdmns

#cd root_domain

#rm *

#ln –s/dev/disk/dsk1a

#cd ..

#cd usr_domain

#rm *

#ln –s/dev/disk/dsk1g

#cd /mnt/etc

#vi sysconfigtab

将swapdevice=/dev/disk/dsk0b修改为swapdevice=/dev/disk/dsk1b

6). SHUTDOWN系统，在SRM下，用新盘引导

恢复文件系统中某些目录或文件：

#vrestore –if/dev/ntape/tape0_d1

(/) add vmunixgenvmunix （在系统根区备份中只恢复vmunix和genvmunix两个文件）

（/） extract (开始恢复)

对个别或若干个目录单独恢复同上

*** 作磁带机需要注意的几个问题

磁带机在备份过程中是分段记录的，在恢复时一定考虑磁带的位置问题。按上述备份例子，在数据带上一共创建了3段独立的数据备份信息（//usr/var）。以下命令可调整数据带的位置。

#mt rewind (磁带机回卷磁带到初始位置)

需要单独恢复/usr文件系统或个别文件信息：

#mt rewind

#mt fsf 1 ( 跳过第一个数据备份段 / )

如果以上需求发生在/var上则：

#mt rewind （跳过前两个数据备份段）

#mt fsf 2

2. DataGrid DDS产品介绍

2.1.概述:

DataGrid DDS是基于分析oracle redo log技术的Oracle实时复制工具，具有简单灵活、高性能低成本的特点，部署和使用非常容易，对系统资源和运行环境的要求也非常低。DataGrid DDS能够帮助用户在复杂的应用环境下完成容灾备份、异构迁移、业务数据分发、基础数据整合集中等工作。

*DataGrid DDS能做什么？

DataGrid DDS能够满足用户多种业务需求，主要有：

提高系统整体可用性

DataGrid DDS能够帮助用户提高Oracle数据库的可用性，无论是执行计划内停机（如系统升级、备份）还是遇到故障引起的非计划宕机（例如硬件故障、灾难、人为错误等），DataGrid DDS都能尽量减少宕机时间。提高可用性能够最大限度地减少数据丢失、经济损失和生产力的降低。

逻辑灾备和灾难恢复

对于大部分公司而言，灾备是一项巨大的工程，意味着高额的资金投入和人力成本。受到传统复制技术的限制，灾备必须拥有专用的硬件支持和专用的光纤传输链路，灾备距离和系统平台还有诸多的限制。此外，由于传统灾备系统的数据库不能随时打开使用，不但风险不能评估，而且巨大的投入也得不到回报。

DataGrid DDS使用逻辑数据复制技术，传递的是交易信息，因此传输数据量很小，保证了在低带宽环境下实现低延迟的Oracle数据异步复制，软件同时支持实时复制容灾和定时复制备份功能，是一种高效且低成本的数据库灾备方式。DataGrid DDS使用标准的IP网络进行通讯，灾备端的Oracle数据库可以部署在本地或远程容灾中心，距离没有限制。此外，由于复制的目的端数据库始终处于打开状态，因此，当生产数据库遇到计划内或非计划停机时，DataGrid DDS能够支持前端应用程序快速、无缝的切换到灾备数据库。与其它基于磁盘或文件系统的物理复制技术相比，不但省略了漫长的数据库recovery和启动时间，而且能够保证100%的切换成功率。

分担数据库负载

DataGrid DDS逻辑交易复制技术保证了目的端数据库始终处于可用状态，因此对于实时交易处理之外的只读应用，例如批量查询、报表处理、数据备份、统计分析等都可以交给复制的数据库处理。多种应用也不必在同一个交易数据库上争夺资源和时间窗口。生产系统运行和维护的压力得以释放，提高了稳定性，而不同的应用在分布的数据库上也可以得到分别的优化。

业务数据分发

DataGrid DDS能够完成企业范围内数据分发，从交易数据生产库实时复制到一个或多个本地或异地的数据库。DataGrid DDS支持多种数据分发拓扑结构，一对多，多对一，级联复制等。数据分发是一种典型的通过部署多服务器、多数据库来分担负载，提高响应速度的企业应用模式。

跨平台数据迁移

DataGrid DDS支持跨平台的数据传输，复制的源和目的系统可以在AIX、HP-UX、Solaris、Linux之间任意选择。DataGrid DDS同时支持Oracle 9i和Oracle 10g。对于用户来说，不但硬件平台的选择有很大的灵活性，也可以用DataGrid DDS来完成异构平台的数据库同步和迁移工作。

实时复制和批量复制

应用的需求影响着用户使用复制工具的模式，对于容灾和查询应用，连续的实时复制保证目的端数据库拥有和生产系统完全一样的数据状态；而对于定时备份、系统升级和定时分析等应用，用户则希望复制软件做到定时或周期性的批量数据迁移。在DataGrid DDS中批量复制和实时复制是相互独立又紧密结合的两个部分，通过管理员的 *** 作控制，DataGrid DDS完全满足用户在多种应用条件下的需求。

交易统计

DataGrid DDS在完成实时数据复制的同时，也跟踪到了数据库交易数量的变化，通过GUI界面，DBA可以随时查询到生产数据库在指定时间段的交易统计结果，通过分析这些数据，DBA能够量化生产数据库压力的变化，从而为数据库的扩容和升级提供了依据。

增强分析工具

DataGrid DDS提供了简单实用的数据库工具包，包括日志分析工具、文件分析工具、导入导出工具等，工具包能帮助有经验的DBA更深入的分析处理数据库的问题。

2.2.DataGrid DDS技术原理

2.2.1.DataGrid DDS和Oracle Redo Logs

*基于日志分析的实时复制技术

DataGrid DDS通过分析Oracle redo log获得实时交易信息，完成schema或table级别的数据复制。区别于早期的日志分析技术，DataGrid DDS对日志的整合和传输以交易为单位，使用该技术，在拥有高性能的同时还能更好的保证数据传输的一致性和完整性。对生产数据库也不会增加负载。

DataGrid DDS从Oracle redo logs里面获取所有的数据库改变信息。通过对信息的分析整合，DataGrid DDS将完整的交易信息复制到目的端。

DataGrid DDS不是等待Oracle redo log文件写满之后再处理，而是随时读取其数据块内容，间隔时间可以用参数指定，一般是秒级。DataGrid DDS也不会复制Oracle redo log的全部内容到目的端数据库，除指定复制对象（数据表）相关的DML/DDL *** 作之外，其他的信息将丢弃处理。

为了避免可能出现的复制错误，用户需要打开数据库的supplemental logging 和force logging参数以便DataGrid DDS能获取完整的数据信息。

置于裸设备或文件系统（包括ocfs）中的Oracle redo log可以被DataGrid DDS正常读取。如果用户使用的是Oracle 10g，并且将redo log保存在ASM（一种新的Oracle存储格式）中，则需要在裸设备或文件系统上手动创建一组与原有日志同步的redo log member，供DataGrid DDS复制使用。

*Online 和 Archived Redo Logs

Oracle有两种类型的日志：在线日志和归档日志。一般情况下，DataGrid DDS从一组在线日志读取信息，因此，不要求Oracle数据库必须打开归档日志。但在某些特殊情况下，online redo log没来得及分析就被覆盖，此时，如果Oracle是归档模式，则DataGrid DDS将从归档日志读取需要的信息。

2.2.2.复制对象和数据定位

*复制对象的指定

DataGrid DDS支持两种级别的复制：1.用户（schema）级复制；2.表级复制。

用户级复制表示源端数据库指定用户（schema）下的所有表、视图、索引、过程、函数、包、序列等数据对象全部复制到目标端数据库指定的用户下。表级复制表示源端数据库指定用户（schema）下的单个表复制到目标端数据库指定用户下的单个表。

在使用DataGrid DDS时，用户通过编辑配置文件指定源端和目的端复制对象的映射关系，包括源端对象名，目的端对象名，目的主机编号等。源端和目的端对象名称可以不同，但结构必须一致。软件运行过程中，复制对象的映射参数会驻留内存，DataGrid DDS通过日志分析过滤，只处理指定复制对象有关的交易，其它用户或表的 *** 作信息则被丢弃。

*Rowid mapping

早期的数据库逻辑复制软件要求被复制的数据表有主键索引，通过where子句查询的方式来定位DML *** 作的目标行。这种方法在数据修改较多或者表内行数较多的应用环境，特别是Update *** 作频繁的情况下，效率较低。

为了满足海量数据系统的应用要求，DataGrid DDS以Oracle内部rowid为参照进行复制数据定位。系统在初始化过程中会自动创建源端数据行和目的端数据行的rowid mapping映射表，为二进制格式，系统根据该映射关系找到DML *** 作的目标行。Rowid定位技术在海量数据环境下处理Update和Delete *** 作具有较大的性能优势。

2.2.3.分级存储和交易队列

DataGrid DDS在数据传输部分使用了分级存储机制，在遇到系统错误引起的复制中断时，例如硬件故障、数据库故障、网络中断或延迟，分级存储机制能完好的保存已经合成的交易信息，避免数据丢失。这些数据以二进制文件格式存储在文件系统的缓存目录下，直到系统故障解决。恢复从缓存文件传输的中断点开始。

* 源端和目的端分级存储

DataGrid DDS的分级存储分为两级：第一级在复制源端，第二级在复制的目的端。Redo log里边的交易的信息被整合成缓存文件后，首先存放到源端的一级缓存目录；然后经过网络通讯进程处理被发送到目的端系统下的二级缓存目录保存；最后由装载进程负责装载到目的端数据库中。

在网络传输出现中断或大量延迟的情况下，DataGrid DDS在源端仍然继续读取并分析数据库日志产生的交易信息，这些信息暂时不能发送到目标端系统，不断地积累在源端的缓存目录下，直到通讯恢复。源端缓存保证了故障情况下复制数据的完整性。

目的端的缓存目录将保存交易信息文件直到它们正确的装载到目的端的数据库内，如果因为目的数据库的故障或关闭，装载不能进行，从源端传送过来的数据文件将在目的端缓存目录下保存。数据库恢复后，缓存文件会严格按照交易时间顺序进行装载。

*文件的格式和大小

交易信息以文件为单位进行传输、缓存和装载，该文件为DataGrid独有的二进制格式，其内部的表达方式与Oracle内部处理方式相类似，避免了很多复杂的信息转换，因此具有很高的效率。

缓存文件的总量为源端实际产生redo log日志量的1/3~1/4左右。DataGrid DDS不设置缓存空间控制机制，用户可以根据每天交易产生的Oracle redo log日志量和以上比例计算需要预留的缓存空间。

*内存管理和大交易处理

DataGrid DDS启动后，将在源端和目的端系统上开辟多个内存区供各进程使用，用来驻留参数、传递消息信号、缓存分析交易的中间信息等。内存区的大小由系统参数指定，目的是防止无限制的使用内存引起系统资源紧张或系统崩溃。

在复制源端，如果遇到数据库产生非常大的交易，DataGrid DDS会连续分析直到整个交易提交，其间产生的中间信息可能达到GB级。在这种情况下，DataGrid DDS会自动将这些信息缓存在磁盘上等待处理，磁盘缓存由后台进程自动处理，容量没有限制。

*交易队列

DataGrid DDS严格按照Oracle数据库内部SCN顺序执行交易的复制和装载，保证复制数据的绝对一致性。

DataGrid DDS在跟踪redo log过程中，每隔一个固定的时间（通常是秒级）读取一次日志文件，分析出本次读出数据的内容，同时记录下该段数据的起始和终止SCN号。下一次读取redo log时，从上一次获取的终止SCN位置开始。多个实例的RAC模式下，则以SCN为参考给每个实例执行的交易进行排队，然后按照排队顺序形成缓存文件。缓存文件也严格按照交易的顺序进行编号、传递。所有的交易在目的端装载的顺序与它们在源端产生的顺序完全相同，这是保证数据完整性和一致性的关键。

2.2.4.使用和部署DataGrid DDS

*在线部署

DataGrid DDS的安装非常简单，不需要特殊的软硬件支持，软件本身完全在Oracle数据库的外部，不需要在Oracle中增加表空间，不需要在复制的表上添加索引和主键，也不需要停机做基础数据同步工作。

整个安装过程可以在线进行，甚至可以在数据库正常执行交易的过程中执行，因为DataGrid DDS不用借助任何第三方工具就可以进行在线的批量数据初始化工作，初始化结束后，无缝切换到增量数据复制过程。这样的功能对于一些需要7*24连续运行的系统来说非常重要，因为在安装维护过程中，频繁的停机会给生产系统带来很大的安全隐患和工作难度。

*跨平台支持和兼容性

使用逻辑复制技术的DataGrid DDS，其跨平台能力是用户非常欢迎的。DataGrid DDS能够支持不同版本Unix/Linux系统下的混合复制，对于具有复杂硬件环境的企业系统来说，异构能力可以节省大量的资源和成本，旧设备得到充分的利用。

不同Oracle版本的支持能力也非常有价值，对于一些7*24运行的Oracle9i数据库来说，DataGrid DDS可以帮助它们在线的升级到Oracle 10g。

*** 作系统 数据库版本 数据类型 数据对象

AIX Oracle9i NUMBER Table

HPUX Oracle9i RAC CHAR View

HPUX（IA64） Oracle VARCHAR/VARCHAR2 Package

Solaris Oracle10g RAC DATE Package body

Linux TIMESTAMP Index

BLOB/CLOB Sequence

RAW/LONG RAW Procedure

ROWID Function

Trigger

表1：DataGrid DDS支持的系统及对象

*多种复制模式

DataGrid DDS支持一对一，一对多，多对一，以及级联复制等多种复制模式。无论在哪种模式下，复制的源和目的系统都是独立的部分，可以单独的使用、维护和优化，这也是逻辑复制技术受到用户青睐的重要原因之一。

一对一的复制常见于灾备应用

比较了三种情况下的 延迟 和 吞吐量 ：双主机，进程间 和 进程内。

在所有测试的情况下，Fast RTPS所提供的等待时间更短，吞吐量更高。

测试环境

系统为： Ubuntu 18.04.2 LTS bionic

内核 为： Linux 4.15.0-64通用内核

机器的规格为：

架构：x86_64

处理器：8

每个核心线程数：2

型号名称：Intel（R）Xeon（R）CPU E3-1230 v6 @ 3.50GHz

DDS中间件版本：2019年9月17日在主仓库上的最新版本

Fast RTPS 1.9.x：010ac53

Cyclone DDS ：801c4b1

OpenSplice DDS：v6.9

对比测试项 （延迟、吞吐量）

延迟测试

测量延迟方法：

在网络计算中，延迟时间定义为 对消息在系统上花费的时间的度量 。也就是说，衡量消息自发送方发送以来经过的时间直到被接收方接收到为止 。为了避免发布者和订阅者所在的系统之间的时钟同步问题，一种近似的延迟方法是通过往返时间。在这种情况下，发布者发送一条消息，并等待订阅者将其发送回（类似于乒乓范式），从而测量发布者的发送 *** 作与发布者的接收 *** 作之间的经过时间。为了获得等待时间的近似值，将测得的往返时间除以2。

统一测试环境和配置 ：

为了执行 测试 ，每种消息大小都会发送 10000 条消息，并提取最小和平均测量值。

DDS QoS 的配置如下：

可靠性(Reliability)：RELIABLE

历史记录类型（History kind）：KEEP_LAST

历史深度(History depth)：1

持久性(Durability)：VOLATILE

-本地主机比较-进程内：

结论 ：本地主机和双主机的比较都显示了Fast-RTPS与其他两个实现之间的明显区别。可以看出，Fast-RPTS的平均延迟始终小于其他实现的最小值。重要的是要注意，Fast-RTPS延迟对于更多的有效负载是稳定的，与CycloneDDS或OpenSplice相比，在较大的有效负载中以较小的增加速率增加。在这种情况下，还值得注意的是，尤其是在双主机情况下，Fast-RTPS均值更紧密地遵循最小值，这意味着最小值和最大值之间的差异始终都较小（均值周围的分布较窄）。

吞吐量 测试

测量吞吐量方法:

在网络计算中， 吞吐量定义为每单位时间可以通过系统发送/接收的信息量的度量，即每秒测量多少比特穿越系统的度量 。正常的测量 *** 作是使发布者在一定时间（ burst interval）内发送大量消息。在完成发送之后，如果 *** 作花费的时间少于突发间隔（ burst interval），则发布者将处于休息状态，直到间隔完全过去（否则，发布者将无法休息）。执行此 *** 作，一直到测试时间。在接收方，接收信息，记录接收到第一条消息的时间，并对到达的每条消息进行计数。测试完成后，接收方可以计算接收采样率。知道每个消息的大小（以位为单位），吞吐量就是采样率乘以消息大小的乘积。下图说明了此过程。

统一测试环境和配置：

通过使用以下工具进行测试比较：

为了执行实验，使用了100、200、500、1000、10000、20000、30000、40000和50000条消息的需求。

为了执行实验，使用了0、10、20、30、40、50、60、70、80、90和100 ms的突发间隔 （ burst intervals ） 。

一些内核的缓冲区已 配置为 以最大化信息流，

net.core.rmem_default = 21299200

net.core.rmem_max = 21299200

net.ipv4.udp_mem = 102400 873800 21299200

net.core.netdev_max_backlog = 30000

使用以下软件版本进行了 测试 ：

Fast-RTPS commit：0bcafbde1c6fa3ef7285819980f932df910dba61

CycloneDDS commit： aa5236dea46b82e6db26a0c87b90cedeca465524

OpenSplice version：v6.9

DDS QoS 的配置如下：

可靠性(Reliability)：RELIABLE

历史记录类型（History kind）：KEEP_ALL

持久性(Durability)：VOLATILE

结论 ： 本地主机比较显示了Fast-RTPS与其他两个实现之间的明显区别。可以看出，Fast-RPTS的吞吐量是每个有效载荷最高的。关于双主机比较，Fast-RTPS和CycloneDDS都显示了几乎等效的吞吐量，最高有效负载为256字节，但是大于256字节后两者之间的差异变得很大，可以看出Fast-RTPS 更出色。（？但是什么在2048->4096->8192会掉下来？）

最后： 这表明Fast-RTPS是在所有测试情况下最快的消息传递实现。此外，在处理消息传递延迟时，Fast-RTPS是最一致的一种。这一切都意味着，使用Fast-RTPS，经历的延迟是最短的，并且始终保持几乎相同。

整理翻译自： https://www.eprosima.com/index.php/resources-all/performance/fast-rtps-vs-cyclone-dds

---