日志备份和按时间删除日志脚本实现

2019/2/25 星期一

需求:在生产上,要把服务器日志传到日志备份服务器上 生产服务器上只保留7天前的日志 用shell脚本实现

备份脚本为

[root@xxx scripts]# cat back_log.sh
#!/bin/bash
#majihui
#backup prd3 block log to ip
#2019/2/25

/usr/bin/rsync -az /ivargo/log/* root@ip:/ivargo/prd3/$HOSTNAME/

然后做定时任务,每天凌晨1点传到备份服务器上
删除日志脚本,每天晚上当时2点开始删除

[root@xxx scripts]# cat rm_7date_log.sh
#!/bin/bash
#majihui
#backup prd3 block log to ip
#2019/2/25

find /ivargo/log/ -type f -name "*log.2*" -mtime +6 |xargs rm -f
[root@xxx scripts]# crontab -l
#backup /ivargo/log to ip:/ivargo/prd3/
0 1 * * * /bin/sh /opt/scripts/back_log.sh >/dev/null 2>&1
#rm 7date log /ivargo/log
0 2 * * * /bin/sh /opt/scripts/rm_7date_log.sh >/dev/null 2>&1

提示:需要在备份服务器上提前创建好相应的分组目录,备份日志的时候,需要与备份主机建立好免密登陆。

扩展:
上面的find命令还可以写成
find /ivargo/log/ -type f -name "log.2" -mtime +6 -exec rm -f {} \;
例子

[root@NewCDH-0--144 log]# find /ivargo/log/ -type f -name "*log*24"  -exec ls -l {} \;
-rw-r--r-- 1 root root 0 Feb 25 13:05 /ivargo/log/NewCDH-0--144.log.2019-02-24
-rw-r--r-- 1 root root 0 Feb 25 13:23 /ivargo/log/vpush/NewCDH-0--144.log.vpush.2019-02-24
[root@NewCDH-0--144 log]# find /ivargo/log/ -type f -name "*log*24"  -exec rm -f {} \;
[root@NewCDH-0--144 log]# find /ivargo/log/ -type f -name "*log*24"  -exec ls -l {} \;

原文地址:https://blog.51cto.com/12445535/2356335

时间: 2024-11-14 12:37:09

日志备份和按时间删除日志脚本实现的相关文章

SQL Server 2014 日志传送部署(7):日志传送故障转移和删除日志传送

13.4 故障转移 13.4.1 故障定位 在前几节明确的提及到,日志传送由三个基本的作业组成:备份作业.复制作业和还原作业.通过上一节日志传送监控功能来定位哪一个作业出了问题: 如果备份作业出了问题,检查主服务器状态. 如果还原作业出了问题,检查辅助服务器状态:或者辅助数据库处于STANDBY模式时用户正在使用辅助数据库. 如果复制作业出了问题,检查除了辅助服务器状态外,还需要检查网络状态. 13.4.2 故障转移 日志传送的故障转移除了考虑切换技术操作以外,更需要考虑主服务器和辅助服务器之间

EntLib6 日志RollingFlatFileTraceListener按实际时间命名日志文件名

关于EntLib的各种构成.原理什么的网上随便找就能找到一大堆相应文章,这里就不细述此部分的相关内容 在使用中,发现RollingFlatFileTraceListener记录下来的日志文件名居然与实际记录的日志Timestamp不一致,比如日志文件内记录的日志是2015-01-20 10:00的,你会发现实际该日志文件的名字为2015-01-20-10:01甚至可能更后(假定设置的RollInterval为Minute,设定的timeStampPattern为yyyyMMddHHmm),因为E

SQL SERVER完整、差异和事务日志备份及还原(脚本和GUI实现) [原创]

一.完整备份.差异备份和事务日志备份的脚本 --完整备份数据库 BACKUP DATABASE Test_Bak TO DISK = 'E:\20150609_75\bak\Test_bak_full.bak' WITH INIT --差异备份数据库 BACKUP DATABASE Test_Bak TO DISK = 'E:\20150609_75\bak\Test_bak_diff.bak' WITH INIT, DIFFERENTIAL --加上DIFFERENTIAL代表差异备份 --事

sqlserver全备份,差异备份和日志备份

差异备份是以上一个全备为基点,这个期间所有差异数据的备份. 日志备份是基于前一个全备+日志备份为基点,这个期间的事务日志的备份.(日志备份用于确保还原数据库到某个时间点) 在利用全备+日志备份时,需要有序并逐个还原所有日志备份.假设要还原周六的数据,则需要上周日的全备和周一到周六的所有日志备份才可以.如果有每天的差异备份,则只需要周日的全备+周五的差异备份+周六的日志备份即可.这样还原起来方便快捷,节省时间成本. 数据正常备份计划 1) 每周星期日的2:00:00执行数据库的完整备份: 2) 每

MsSQL利用日志备份恢复到某一时间点

在做update或delete操作时忘带where条件或where条件精度不够,执行之后导致数据丢失或更新错误等严重后果,如果你的数据库已有相应的完整备份,并且不能备份日志(truncate log on checkpoint选项为1)可以利用事务日志的备份来进行数据恢复. 恢复数据具体步骤如下: 1,首先要做的事就是进行一次日志备份(如果为了不让日志文件变大而置trunc. log on chkpt.选项为1那就没法子了)     backup log dbName to disk='D:\N

Oracle 10g 添加、删除日志组

做日常巡检的时候发现alert日志中有这个错误Thread 1 cannot allocate new log, sequence 319708Checkpoint not complete 这个实际上是个比较常见的错误.通常来说是因为在日志被写满时会切换日志组,这个时候会触发一次checkpoint,DBWR会把内存中的脏块往数据文件中写,只要没写结束就不会释放这个日志组.如果归档模式被开启的话,还会伴随着ARCH写归档的过程.如果redo log产生的过快,当CPK或归档还没完成,LGWR已

SQL Server中的事务日志管理(7/9):处理日志过度增长

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 这篇文章会列出导致事务日志过度增长的常见的问题和错误管理形式,包括: 在完整恢复模式里,没有进行日志备份 进行索引维护 长时间运行或未提交的事务阻止事务日志里空间重用 当然,如果增长没检查,日志文件会扩展直到吞没所有可用磁盘空间或日志文件的最大大小,在这个时候你

SQL Server中的事务日志管理(3/9):事务日志,备份与恢复

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 它不会经常提起,除非你的数据库运行在简单(SIMPLE)恢复模式,在事务日志上定期备份非常重要的.这会控制事务日志大小,并且保证,在灾难发生里,你可以恢复你的数据库到灾难发生前的某个时间点.这些日志备份要和定期的完整数据库(数据文件)备份一起. 如果你在测试数据

SQL Server中的事务日志管理(6/9):大容量日志恢复模式里的日志管理

当一切正常时,没有必要特别留意什么是事务日志,它是如何工作的.你只要确保每个数据库都有正确的备份.当出现问题时,事务日志的理解对于采取修正操作是重要的,尤其在需要紧急恢复数据库到指定点时.这系列文章会告诉你每个DBA应该知道的具体细节. 这个标题有点用词不当,因为运行在大容量日志恢复模式里的数据库,我们通常是长期不管理日志.但是,DBA会考虑在大容量加载时,短期切换到大容量恢复模式.当数据库在大容量模式里运行时,一些其他例如索引重建的操作会最小化日志(minimally logged),因此在日