BiT not finding new directories

[Chris O'Neill]

Hi:

I'm running BiT 0.9.26 on Fedora 12 Linux (kernel 2.6.32.9-70.fc12.x86_64 with backups going to an external USB hard drive. All seemed to be working well (i.e. snapshots being taken, etc.) until I noticed that BiT is not taking snapshots of new directories. For instance, I was doing weekly snapshots of the whole hard drive, including /usr. I recently installed new software into the /usr/share directory. When BiT does the weekly snapshot of /usr it includes all of the directories in /usr/share *except* the new one.

I turned off scheduling and tried a "Now" snapshot... same result. I even explicitly added the directory to the "include" list and took another "Now" snapshot... still no go. Further looking confirmed that this is happening in other directories (e.g. /usr/src).

Is this normal behavior for BiT? Am I missing something?

Thanks for any help/advice provided.

Regards, Chris

[Dan (danleweb)]

You have to exclude:
- "/home/chrison/.gvfs" => this contains runtime information; no need to backup
- "/proc" => this contains runtime information; no need to backup
- "/selinux" => if you want to back it up (but I don't really think it is needed) you need to do it as root because as normal user you don't have enough rights
- "/sys" => this contains runtime information; no need to backup

and then try again.

[Chris O'Neill (chrison999)]

Nice to hear from you again, George:

We're paid-up here until sometime around the 5th (can't remember the
exact date, and too lazy to look it up right now.) :D We might stay a
bit longer, depending on how things go, but we'll definitely be heading
to the coast while you're in Mesa, so we'll call you at the number you
gave when we get into Phoenix. Let's plan for a photo shoot at your
favorite places (we don't know Phoenix all that well), and maybe a night
out at a nice place.

Have a safe trip! We'll talk to ya later...

Regards,

Chris and Cori

On Mon, 2010-03-29 at 00:25 +0000, Chris O'Neill wrote:
> Okay, did that. New log file attached.
>
> Regards,
>
> Chris
>
> P.S. I did run "backintime -b" as root (i.e. did a su - first), and the
> regular backups run as root from a cron job.
>
>
> ** Attachment added: "BiToutput.txt"
> http://launchpadlibrarian.net/42328502/BiToutput.txt
>

[Chris O'Neill (chrison999)]

Okay, did that. New log file attached.

Regards,

Chris

P.S. I did run "backintime -b" as root (i.e. did a su - first), and the regular backups run as root from a cron job.

[Chris O'Neill (chrison999)]

To the System Admins: My apologies for the personal email posted above as a comment to the bug report. My email package had a hiccup (or maybe it was me?). Please delete that comment and this one. I would,, but i don't see a "delete" button.

Again... sorry!

Regards,

Chris

[Dan (danleweb)]

Looks much better :)

The only remaining problem is "/dev". If think you can exclude it too.
If not what is your destination file system ? I think you should use a linux one (ext3/4, ... ) if want nodes.

Regards,
Dan

[Chris O'Neill (chrison999)]

The destination drive is a 1Tb Western Digital My Passport USB drive formatted as one large ext3 partition. I can exclude /dev to get rid of those final errors, but isn't that going to cause problems if I have to do a system restore? (I'm not really all that familiar with the inner workings of Linux, but doesn't /dev contain some pretty important stuff (like links to hardware devices, etc.)

Anyway, you've resolved most of the unrelated problems I was having, for which I'm very thankful, but the main issue still remains... BiT isn't picking up changes to the system properly. For instance, yesterday these directories were added to the system but are not included in last night's backup:

/usr/src/SimGear-1.9.1
/usr/src/Atlas

As well, this directory was removed from the system but it's still showing up in the snapshot from last night:

/usr/src/SimGear-1.0.0

There may be other directories/files that were added/removed that BiT missed, but these are the ones I know that definately changed.

Rgards,

Chris

[Dan (danleweb)]

"/dev" can be populated on boot and runtime (if you plug it a device).

At least for tests please remove it and run again "backintime -b" from a console.
I hope I'll find something usefull.

Regards,
Dan

[Chris O'Neill (chrison999)]

"/dev? removed from the backup list. log file attached ("backintime -b" ran as root).

Regards,

Chris

[Dan (danleweb)]

I think is more because of set_acl (xattr).
BIT should have options to enable/disable xattr and not use the all the time.

[Chris O'Neill (chrison999)]

I'm not sure what "set_acl (xattr)" means? Is this a coding problem, or something that I can configure/change as an end user? Also, I appreciate your changing the status to "Confirmed - Medium Importance" but I'm wondering if "Medium Importance" is understating the problem? The fact that BiT sometimes doesn't recognize new directories is a pretty serious problem for a backup application, IMHO. Until the problem is fixed, whenever an end user creates a new directory he/she MUST check to make sure that BiT is picking it up and including it in the backup cycles... NOT a good situation!

Regards,

Chris

[Dan (danleweb)]

You can learn about xattr here: http://en.wikipedia.org/wiki/Extended_file_attributes

BIT is just a GUI. The real job is done by rsync. If the arguments are wrong then it is BIT fault. If not ...
But not including all the data it is a serious problem.

[buhtz (buhtz)]

The project and this report moved to GitHub
https://github.com/bit-team/backintime/issues/80

Can you please give us feedback if this is still relevant or can we close the Issue?