Page 3 of 3 FirstFirst 123
Results 21 to 23 of 23

Thread: / full 91%

  1. #21
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: / full 91%

    Quote Originally Posted by Quarkrad View Post
    As rdiff-backup is my backup tool I did a search for rdiff-backup and found many of files. However, they were (in total) small and looked like the application files themselves. Searching for actual file names that would have been backed up by rdiff-backup resulted in nothing, so it looks to me, there are no partial rdiff-backups in /
    To find if any rdiff-backup versions are in a tree, use
    find /path/to/tree -type d -iname rdiff-backup-data/

    So, on my backup server, I put backups onto a mount somewhere, but make a convenience symlink from /Backups to that location. That means I need to trick "find" into dereferencing the top link into the mount ... using "/Backups/" with the trailing / character. Without that, it is on the / file system, not the other one. I need sudo because backup areas can be blocked off so only root has access. There are definitely some subdirs on each system that only root can access as well. That's how I roll/role.
    Code:
    sudo find /Backups/  -type d -name rdiff-backup-data
    That searches for the versioning directory for each backup area (I probably have 15-20 different systems on that disk).

    The find takes a long while. A few results are:
    Code:
    /Backups/cb35/rdiff-backup-data
    /Backups/lubuntu/rdiff-backup-data
    /Backups/mail.jdpfu.com/rdiff-backup-data
    /Backups/romulus/rdiff-backup-data
    ....
    You get the idea.

    If you don't really know where, then mount each file system under the Try Ubuntu environment ... perhaps to some temporary mounts like:
    /mnt/a1
    /mnt/a2
    /mnt/a3
    /mnt/b1
    /mnt/b2
    /mnt/b3
    ....
    and use
    Code:
    sudo find  /mnt/ -type d -name rdiff-backup-data
    This won't work running in the normal environment or with the partitions mounted where they normally would be mounted. That's the problem that is hiding there the data is - there is almost certainly a mount placed over the files you want.

    You can also look through the different rdiff-backup sets and look for missing days in your list. I backup daily, but sometimes my laptop isn't on when it is time for backups ... so a few days each week don't happen. It is just a laptop and doesn't actually have anything critical on it. It is never my "system of record" for anything. Anyway,
    Code:
    $ sudo rdiff-backup --list-increments /Backups/posc
    Found 80 increments:
        increments.2021-06-20T00:07:03-04:00.dir   Sun Jun 20 00:07:03 2021
        increments.2021-06-22T00:07:03-04:00.dir   Tue Jun 22 00:07:03 2021
        increments.2021-06-23T00:07:04-04:00.dir   Wed Jun 23 00:07:04 2021
        increments.2021-06-24T00:07:04-04:00.dir   Thu Jun 24 00:07:04 2021
        increments.2021-06-25T00:07:05-04:00.dir   Fri Jun 25 00:07:05 2021
        increments.2021-06-26T00:07:04-04:00.dir   Sat Jun 26 00:07:04 2021
        increments.2021-06-27T00:07:03-04:00.dir   Sun Jun 27 00:07:03 2021
        increments.2021-06-28T00:07:03-04:00.dir   Mon Jun 28 00:07:03 2021
        increments.2021-06-29T00:07:03-04:00.dir   Tue Jun 29 00:07:03 2021
    ...
        increments.2021-09-12T00:07:04-04:00.dir   Sun Sep 12 00:07:04 2021
        increments.2021-09-13T00:07:03-04:00.dir   Mon Sep 13 00:07:03 2021
        increments.2021-09-15T00:07:04-04:00.dir   Wed Sep 15 00:07:04 2021
        increments.2021-09-16T00:07:03-04:00.dir   Thu Sep 16 00:07:03 2021
    Current mirror: Fri Sep 17 00:07:05 2021
    So, it is clear that Jun 21st, Sept 11th, 14th, backups are missing. On your system, that would be the nights where the backup storage probably wasn't mounted correctly ... so look under the mount location there. The backup needs to be umount'ed to look, right? If all the versions are there, per your automatic backup schedule, none missing, then that isn't the disk you need to worry about. Move on and look for another partition/LV/subvolume (normal/LVM/btrfs storage terms) that may not have been mounted where and when expected, but is now.

  2. #22
    Join Date
    Oct 2008
    Location
    UK
    Beans
    1,640
    Distro
    Ubuntu Mate 20.04 Focal Fossa

    Re: / full 91%

    Finally - solved, / has gone down from 25G to 10G - there maybe other bits & pieces so I will have a closer look around. It seemed my problem was an rdiff-backup that backed itself up to my / partition instead of /media/dad/backup/rdiffbackup where it is supposed to go.. @TheFu gave me a pointer in #17 when he said "Suppose the "automatic mount" for your backup storage didn't work once" - it looks like that is exactly what happened. I will start another thread to get some more information/help on this .NOT-MOUNTED file. Thank you everyone who has helped me with this, to me, confusion.

  3. #23
    Join Date
    Mar 2010
    Location
    Squidbilly-Land
    Beans
    Hidden!
    Distro
    Ubuntu

    Re: / full 91%

    Quote Originally Posted by Quarkrad View Post
    Finally - solved, / has gone down from 25G to 10G - there maybe other bits & pieces so I will have a closer look around. It seemed my problem was an rdiff-backup that backed itself up to my / partition instead of /media/dad/backup/rdiffbackup where it is supposed to go.. @TheFu gave me a pointer in #17 when he said "Suppose the "automatic mount" for your backup storage didn't work once" - it looks like that is exactly what happened. I will start another thread to get some more information/help on this .NOT-MOUNTED file. Thank you everyone who has helped me with this, to me, confusion.
    Actually, in post #5, Impavidus, said
    gparted says it's full, but du doesn't see the files taking all that space. Could it be that some files are hiding underneath a mountpoint? We occasionally have people here who wrote their backups to /media/backups whilst their backup drive was unmounted, then mounted their backup drive and wondered why their disk was full.
    That is what I picked up on and followed as the nearly 100% most likely issue whenever multiple GB is being used, but cannot be located.

    Search the forums for HermanAB's mount-checking/validation technique. It takes advantage of the fact that when we mount a file system on a directory, that hides the files inside. If there is a zero-length file there BEFORE the mount, then after the mount, it won't be seen. Basically, that file uses an inode, but only 1 storage block. Very efficient. None of us invented these things. We all saw someone else doing it first and almost always for exactly this issue.

Page 3 of 3 FirstFirst 123

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •