7-15作业

xtrabackup实现mysql 增量备份

增量是基于已有数据进行备份的,也就行需要先创建一次全量备份,然后记录当时的记录点

1.创建备份

xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/base
 
# 基于全量备份进行增量
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base

2.查看备份类型 确认是增量备份了

    root@longing:/data/backups/inc1# cat xtrabackup_checkpoints 
    backup_type = incremental
    from_lsn = 837943393
    to_lsn = 837943393
    last_lsn = 837943402
    compact = 0
    recover_binlog_info = 0
    flushed_lsn = 837943402


from_lsn 是备份的起始 LSN，对于增量备份，它必须to_lsn与先前 base 备份的相同。

在这种情况下，您可以看到to_lsn （最后一个检查点LSN）和last_lsn（最后一个复制的LSN）之间存在差异，这意味着在备份过程中服务器上有一些流量。我们可以测试一下 对第一个增加继续创建增量 创建增量之前先创建几条数据

xtrabackup --user=bkpuser --password=123456 --backup
–target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1

3.准备恢复

已经有3个备份了,我们要先对基础数据进行准备,然后对两个增量进行准备

xtrabackup --user=bkpuser --password=123456 --prepare–apply-log-only --target-dir=/data/backups/base

xtrabackup --user=bkpuser --password=123456 --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1

xtrabackup --user=bkpuser --password=123456 --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2

xtrabackup --apply-log-only 合并除最后一个以外的所有增量时应使用, 一旦准备好，增量备份就与完整备份相同，可以用相同的方式还原它们。

4.恢复

xtrabackup --copy-back --target-dir=/data/backups/base

原理

在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件.事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的
事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。

Xtrabackup 在启动时会记住log sequence number（LSN）, 并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。这时，xtrabackup 会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。Xtrabackup 必须持续的做这个操作，是因为事务日志是会轮转重复的写入，并且事务日志可以被重用。所以 xtrabackup 自启动开始，就不停的将事务日志中每个数据文件的修改都记录下来。上面就是 xtrabackup 的备份过程

可不可以只用redolog或者只用binlog?
不引入两个日志，也就没有两阶段提交的必要了。只用binlog来支持崩溃恢复，又能支持归档，不就可以了？只保留binlog，然后可以把提交流程改成这样：… -> “数据更新到内存” -> “写 binlog” -> “提交事务”，是不是也可以提供崩溃恢复的能力？

答案是不可以。

如果说历史原因的话，那就是InnoDB并不是MySQL的原生存储引擎。MySQL的原生引擎是MyISAM，设计之初就有没有支持崩溃恢复。

InnoDB在作为MySQL的插件加入MySQL引擎家族之前，就已经是一个提供了崩溃恢复和事务支持的引擎了。

InnoDB接入了MySQL后，发现既然binlog没有崩溃恢复的能力，那就用InnoDB原有的redo log好了。

那能不能反过来，只用redo log，不要binlog？

如果只从崩溃恢复的角度来讲是可以的。你可以把binlog关掉，这样就没有两阶段提交了，但系统依然是crash-safe的。

binlog有着redo log无法替代的功能。一个是归档。redo log是循环写，写到末尾是要回到开头继续写的。这样历史日志没法保留，redo log也就起不到归档的作用。

一个就是MySQL系统依赖于binlog。binlog作为MySQL一开始就有的功能，被用在了很多地方。其中，MySQL系统高可用的基础，就是binlog复制。

还有很多公司有异构系统（比如一些数据分析系统），这些系统就靠消费MySQL的binlog来更新自己的数据。关掉binlog的话，这些下游系统就没法输入了。

总之，由于现在包括MySQL高可用在内的很多系统机制都依赖于binlog。

利用iptbles阻止kali的nmap扫描？
Nmap可以完成以下任务：

    主机探测
    端口扫描
    版本检测
    系统检测
    支持探测脚本的编写

Nmap在实际中应用场合如下：
通过对设备或者防火墙的探测来审计它的安全性
探测目标主机所开放的端口
通过识别新的服务器审计网络的安全性
探测网络上的主机

在Iptables上配置这些命令可以有效阻止nmap扫描
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL SYN -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -R INPUT 1 -s 192.168.80.138 -p tcp --dport 1: --tcp-flags ALL ACK -j REJECT

我们使用kali工具进行nmap功能扫描，检测是否做到有效防御


通过以上现象可以看到可以有效阻止nmap的扫描。