Tim Beauregard wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
James Wu wrote:
I wouldn't dismiss what Marc was onto. If you do the math, 44G in
/documents + 11G in the rest of / == 55G, seems to be a bit more than
coincidence. I know you already tried ls -l /documents/ after you
umounted but just for curiosity's sake, I wonder what happens when you do:
umount /documents
du -sh /documents
du -sh /documents/
4.0K /documents/
I agree with you about 44+11. The mystery if this is the origin of my
problem, is that we are talking about two separate drives (/dev/hdb1 +
/dev/hda1).
What is the result of
umount /documents
umount /maxtor
du -x --max-depth=1 / | sort -n
0 /dev
0 /proc
0 /sys
0 /tmp
4 /documents
4 /mnt
4 /opt
4 /selinux
4 /srv
12 /media
16 /lost+found
24 /root
80 /home
4132 /bin
4228 /sbin
4264 /etc
6520 /boot
68740 /lib
179776 /var
637304 /usr
11136816 /backup
44830668 /maxtor
56872608 /
Very interesting!
t...@server:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda1 57677500 57056884 0 100% /
tmpfs 241824 0 241824 0% /lib/init/rw
udev 10240 696 9544 7% /dev
tmpfs 241824 0 241824 0% /dev/shm
overflow 1024 0 1024 0% /tmp
t...@server:~$ ls -l /maxtor/
total 52
drwxrwxr-- 6 root users 4096 2009-05-18 05:36 2009-05...@05:36:07
drwxrwxr-- 6 root users 4096 2009-05-25 05:50 2009-05...@05:50:07
drwxrwxr-- 6 root users 4096 2009-06-01 05:50 2009-06...@05:50:29
drwxrwxr-- 6 root users 4096 2009-06-08 05:50 2009-06...@05:50:48
drwxrwxr-- 6 root users 4096 2009-06-15 05:50 2009-06...@05:50:24
drwxrwxr-- 7 root users 4096 2009-06-22 05:52 2009-06...@05:52:22
drwxrwxrwx 9 root root 4096 2009-07-13 05:54 2009-07...@05:54:45
drwxrwxrwx 9 root root 4096 2009-07-20 06:02 2009-07...@06:02:14
drwxrwxrwx 9 root root 4096 2009-07-27 06:02 2009-07...@06:02:03
drwxrwxrwx 9 root root 4096 2009-08-17 06:01 2009-08...@06:01:50
drwxrwxrwx 9 root root 4096 2009-09-14 06:04 2009-09...@06:04:43
drwxrwxrwx 9 root root 4096 2009-09-21 06:03 2009-09...@06:03:12
drwxrwxrwx 9 root root 4096 2009-10-05 06:04 2009-10...@06:04:48
So...there is a copy of many OLD faubackups on /dev/hda1!
t...@server:~$ sudo mount /maxtor/
t...@server:~$ ls -l /maxtor/
total 0
drwxrwxrwx 1 root root 0 2009-09-28 06:06 2009-09...@06:06:58
drwxrwxrwx 1 root root 0 2009-11-02 06:13 2009-11...@06:13:59
drwxrwxrwx 1 root root 0 2009-12-07 06:15 2009-12...@06:15:52
drwxrwxrwx 1 root root 0 2009-12-21 06:16 2009-12...@06:16:07
drwxrwxrwx 1 root root 0 2009-12-28 06:15 2009-12...@06:15:57
drwxrwxrwx 1 root root 0 2010-01-04 06:17 2010-01...@06:17:13
drwxrwxrwx 1 root root 0 2010-01-11 06:17 2010-01...@06:17:47
drwxrwxrwx 1 root root 0 2010-01-18 06:18 2010-01...@06:18:44
My backup strategy involves two Maxtor external hard drives, one being
connected for six months and then swapped with the second which has been
stored off site. Somehow the non-connected Maxtor data has been saved
on /dev/hda1.
My easy solution is to umount /maxtor, and delete all the old backups.
I wonder, maybe faubackup can't cope with disappearing data...?
Thanks for any input.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAktgpLoACgkQsUUdIDHrdAUVZQCgjP2I9/aPrOyBagMvLh9h7two
hXAAn0B8g/zacKxYWiSocADeh0vlmGvR
=dODx
-----END PGP SIGNATURE-----
Maybe it is due to the way faubackup works. In the man pages it states :
BUGS
You need a filesystem with stable device id and inode number so that
faubackup can correctly find your files again. This may be violated by
some remote filesystems, for example Samba.
Maybe swapping drives falls into this categorie too.
Bruno
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org