我有一个 rdiff-backup 设置,它通过网络备份较大的 sql 转储(1.6GB)。它备份到的服务器(Ubuntu 10.10 服务器)有一个小型本地磁盘(4GB,1GB 可用),但有一个 cifs 安装到大型 nas(大量可用空间)。我有一个从用户帐户主目录到 NAS 的软链接cifs mount
,rdiff-backup
从客户端发起的作业正在写入该目录。
最近,这项工作一直失败。日志文件显示:
Sun Oct 24 21:20:14 2010 Sending back exception [Errno 28] No space left on device of type type 'exceptions.IOError'
我在服务器上手动运行了该作业watch df
,我可以看到本地驱动器上的 1GB 可用空间逐渐减少,直到达到零。然后作业失败。需要明确的是,磁盘空间不是 NAS 上的问题。
因此,出于某种原因,rdiff-backup 使用本地磁盘上的某个位置作为临时工作目录,而不是像我预期的那样使用 NAS 设备上存储备份的实际目录。但是,我找不到它正在使用哪个目录,因此我可以使用自己的空间单独挂载它。在作业运行时执行du -sx
on操作显示总文件大小保持不变,为 3.0GB,尽管它已满。/
/
df
/
如果我列出进程打开的文件句柄rdiff
,我会得到一些套接字和 NAS 挂载上的一些文件。本地磁盘上没有明显的东西。
发生了什么事?为什么df
说/
已满,但du -sx
说还有 1GB 可用?为什么rdiff-backup
在应该使用时却填满了本地磁盘cifs mount
?它实际上写入了什么?
答案1
正如 maco 在评论中提到的,/tmp
这就是问题所在。
使用 rdiff-backup 您可以使用参数配置临时目录位置
--tempdir path
Sets the directory that rdiff-backup uses for temporary files
to the given path. The environment variables TMPDIR, TEMP, and TMP
can also be used to set the temporary files directory. See the
documentation of the Python tempfile module for more information.
如果您将 tempdir 设置为该 CIFS 挂载,问题就会消失。(我们遇到了同样的问题,并且解决了,您可能也会遇到其他问题)
答案2
[Errno 28] No space left on device
我注意到,当对目标目录的写访问被中断(例如由于 USB 电缆松动)时,也会发生同样的错误。
故障发生后,承载目标目录的卷可能仍处于挂载状态,但为了安全起见,该卷将恢复为只读。因此,当用户再次尝试使用 rdiff-backup 时,它将再次失败,并出现相同的错误。
如果是外部 USB 驱动器,请断开并重新连接驱动器。之后,rdiff-backup 应该可以再次工作。
答案3
无论我做什么,rdiff-backup 都希望使用超过 120gb 来节省 60gb,所以我就这么做了rsync -av (源目录) (目标目录)反而。