真心求解。
数据丢失一共发生两次(至少有感觉的是两次,没发现的不清楚)。
先说一下个人环境吧。
Arch和win8.1双系统,Arch桌面环境是gnome-shell。
Arch把所有testing全开,添加了archlinuxfr源,通过yaourt安装了下列软件包:
adduser、gnome-shell-extension-kimpanel-git、grub-btrfs、grub-hook、iptables-nftables、kingsoft-office、laptop-mode-tools、radeontop、rhythmbox-tray-icon、update-grub;
分区情况:(仅做参考,和问题关系不大)
MBR引导的128G SSD+GPT的1TB机械硬盘;
sda1:100MB 品牌机保留
sda2:40GB win8.1 update 1(已确认数据丢失由Arch引起,和win无关)
sda5:200MB Linux ext4,挂载点:/boot
sda6:8GB swap
sda7:63.5GB btrfs,挂载点:/,/home
sdb1:544GB NTFS数据分区
sdb2:387.5GB ext4数据分区
================
说一下数据丢失的情况:
第一次是某个周六深夜,正在看电影。通过samba把存放在远程设备的电影拉到本地的/tmp下,边复制的同时,用gnome-mplayer打开正在复制的/tmp下的电影来播放。samba服务器是华为HG255D路由器,运行OpenWRT系统,通过gvfs在nautilus中访问。
看到看完之后退出播放器,发现GTK主题变成默认白色的了。我之前是改成全局黑色。仔细一查找,/home下和sdb2下的很多文件莫名其妙不见了,而GTK主题变为默认就是因为配置文件丢失。
后来清点了一下,这两个目录下丢失了数十GB的文件,而使用MTP协议连接在电脑上的Android手机则丢失了20GB左右的数据。
第一次发现丢失之后,应对措施是下载了clamav,进行了全盘扫描,但发现的所谓威胁,其实全都是NTFS分区中的exe和cab文件,且大多是正常文件,并无感染迹象。
而第二次数据丢失,则是发生在上周六深夜,即7月12日晚。当时也是在用和第一次丢失数据时一样的方法看电影,但samba服务器换了一台了,是树莓派,运行ArchLinux-arm系统,也是通过gvfs在nautilus中访问,且gvfs对远程samba服务器具有读写权限。而本次数据丢失,是samba服务器上的硬盘!!!丢失数据量达到接近800GB!!!
=================
总结一下两次数据丢失的共同点:
都是在周六晚到周日的交界(数据实际发生丢失应该是在周日的零点之后,即新一周的刚开始);
都是从samba服务器上拷贝电影到/tmp下,且边拷贝边观看;
发生数据丢失的分区虽涵盖了btrfs、ext4、FAT32_on_mtp、NTFS_on_samba,但系统当前登录的用户都对丢失的数据具有读写权限,当前用户无权限的目录毫发无损;
丢失的文件普遍创建时间较早。新近创建的文件丢失得很少。那块丢失了近800GB数据的盘是我的数据备份仓库,文件创建时间都较早,所以损失最大;
对出现问题的分区在各种系统下进行fsck,都未出现异常,而且未丢的文件都还很完整,看症状更像是直接删掉的,所以NTFS分区的数据可以几近完全数据恢复;
都是在ArchLinux下发生,第一次是3.15.3还是3.15.4来着,忘了。。。第二次是在3.15.5内核下。
额,废话有点多,但真心是大问题啊。。。800GB的数据丢失所幸是在NTFS分区下的,可以数据恢复,但已经连续回复快一天了,只恢复到外部设备。。。
希望各位能帮忙分析一下,也是为了广大用户的数据安全:(
离线
很明显是有程序以当前用户身份删掉了那些文件嘛。
可以用 inotifywait 来监视文件的访问情况:
inotifywait -e delete -m -r 要监视的目录
不过是看不到是谁在删文件的。如果你一直盯着它看的话能知道是什么时间删除的。
然后你可以在那个时候用 root 用户执行 killall -u 你的用户名 -STOP 来停止你的所有进程,用 htop 和 lsof 慢慢检查。完事之后再发 SIGCONT 信号恢复执行。
对了,你 crontab -l 检查一下是不是有奇怪的 cron 任务?
最近编辑记录 依云 (2014-07-14 19:06:29)
离线
很明显是有程序以当前用户身份删掉了那些文件嘛。
可以用 inotifywait 来监视文件的访问情况:
inotifywait -e delete -m -r 要监视的目录
不过是看不到是谁在删文件的。如果你一直盯着它看的话能知道是什么时间删除的。
然后你可以在那个时候用 root 用户执行 killall -u 你的用户名 -STOP 来停止你的所有进程,用 htop 和 lsof 慢慢检查。完事之后再发 SIGCONT 信号恢复执行。
对了,你 crontab -l 检查一下是不是有奇怪的 cron 任务?
谢回复。
各用户的crontab和nautilus的script都检查过了,没有可疑的东西。/etc/cron.*也都检查过了。。。
至于监视删除,比较不靠谱,因为丢失数据的分区比较不确定,而且不知道它什么时候要删一次数据。。。
离线
那难道只能用 systemtap 了么……
离线
那难道只能用 systemtap 了么……
刚搜了一下systemtap,有点高大上的感觉。。。完全没有头绪。不过谢啦,我有空看看。
不过不知道systemtap究竟能获取哪些信息。。。
离线
百合仙子 说:那难道只能用 systemtap 了么……
刚搜了一下systemtap,有点高大上的感觉。。。完全没有头绪。不过谢啦,我有空看看。
不过不知道systemtap究竟能获取哪些信息。。。
可以在删除文件的时候获取是哪个进程在删什么文件呗。
不过你需要一个带调试符号的内核。
离线
Systemd 会定时启动一些进程, 比如 systemd-tmpfiles-clean.timer 会清理 /tmp. 可以看下各个 Timer 的启动时间是不是有可疑的.
离线
换个用户名重新配置
预防下,文件系统的cow或者unionfs。
sysstat的sa有统计任何时间点的系统信息,当然就有io,修改下间隔时间,还可以记录其他信息
最近编辑记录 atmouse (2014-07-15 16:03:46)
离线
多谢楼上几位的解答。我会按照楼上几位的方法尝试排查问题所在。
离线
alien_hjy 说:百合仙子 说:那难道只能用 systemtap 了么……
刚搜了一下systemtap,有点高大上的感觉。。。完全没有头绪。不过谢啦,我有空看看。
不过不知道systemtap究竟能获取哪些信息。。。可以在删除文件的时候获取是哪个进程在删什么文件呗。
不过你需要一个带调试符号的内核。
最近正打算换到3.16-rc5。感觉3.15.2之后各种说不出来的让人不舒服。
正如你说,我编译的时候把调试符号支持加上就是了~
离线
Systemd 会定时启动一些进程, 比如 systemd-tmpfiles-clean.timer 会清理 /tmp. 可以看下各个 Timer 的启动时间是不是有可疑的.
刚看了一下,系统中未启用任何timer,crontab也是干净的。
离线
换个用户名重新配置
预防下,文件系统的cow或者unionfs。
sysstat的sa有统计任何时间点的系统信息,当然就有io,修改下间隔时间,还可以记录其他信息
换用户不如直接重装系统。。。
话说,FX8350和GCN显卡在Linux开源驱动下支持程度如何?有意毕业之后搞AMD的八核来跑make
离线
百合仙子 说:alien_hjy 说:百合仙子 说:那难道只能用 systemtap 了么……
刚搜了一下systemtap,有点高大上的感觉。。。完全没有头绪。不过谢啦,我有空看看。
不过不知道systemtap究竟能获取哪些信息。。。可以在删除文件的时候获取是哪个进程在删什么文件呗。
不过你需要一个带调试符号的内核。最近正打算换到3.16-rc5。感觉3.15.2之后各种说不出来的让人不舒服。
正如你说,我编译的时候把调试符号支持加上就是了~
要支持 systemtap 不仅仅需要调试符号的。你在 Arch 官方内核配置上加上调试符号就可以,另外你需要 System.map 文件,systemtap 会告诉你怎么处理。
或者直接安装社区源里的 linux-lily-debug 包(systemtap-git 包也有) =w=
离线
我把这个问题发到百度Linux贴吧里,虽没解决,但有个人跟我遇到一样的问题。据描述,应该都是由nautilus引起的。
贴吧上那个人描述说,当时他被删的数据,必须有root权限才能删,而他只给nautilus赋了权限。被删的数据也都是时间戳比较旧的数据。
而我第二次被删的数据是在samba上,只有nautilus和gvfs有能力接触那部分数据。
所以我认为基本可以确定是nautilus或者它的小伙伴的问题了。。。
离线
我这两天遇到类似的问题
debian testing + archlinux
第一次两台 archlinux掉数据很严重,连系统都起不来了,有一台连/sys, /proc 这些都不见了
重装系统后,发现又出现,这次是把两台机器的debian的数据给搞掉了,分析了几次都有个共同点就是全都挂在/tmp/下
/tmp/debian , /tmp/arch64
通过 sudo journalctl 查看日志发现,今天两台电脑debian系统掉数据前都打印了以下的信息
systemd[1]: Starting Cleanup of Temporary Directories...
搜索了一下发现systemd-tmpfiles-clean.service 会去调用,另外/usr/lib/systemd/system/systemd-tmpfiles-clean.timer 会自动定时15分钟去调用一次
记得一两个月前有一次挂了windows 7的C盘到/tmp/下拷几个文件,然后重启后发现windows进不去了,当时重装系统没注意
可以sudo systemctl start systemd-tmpfiles-clean.service
sudo journalctl -b | grep "Starting Clean" 来查看日志
目前还在验证到底是不是由它引起的
离线