Back In Time

Initial snapshot OK; next snapshot with only additions?

Asked by Joost 't Hart

Context: BIT 1.0.34-01 (ubuntu, kde) to a NAS, nfs mounted.

Initial snapshot creation went fine, except for some obvious error report on some .trash folder.

After adding a new directory with some file stuff to one of the "roots" in the backup set, I decided to give it an immediate test shot. None of the already existing files in the backup set, except <new folder>/.. for that matter - were changed.

The snapshot log gives
  * the [C] cd++++ etc and [C] >f+++++ entries for <new folder>/*. That's reassuring; the rsync compare works fine.
  * the cp -aRl to a new_snapshot directory
  * follows a long list of rsync delete infos (the unchanged files, I guess)
...
  * do not follow any additions, nor errors

Result: My new_snapshot is perfectly empty

Any clues why the newly added material was not added into the new_snapshot?

Cheers and thanks,
Joost.

PS: In a sort of clueless mood, I started another (3rd) snapshot, which is still running. It started off with a comparison against the empty snapshot ;-). It found and added the <new folder>... So this will become a big one again, with all fresh copies I assume?

PS 2: I verified that cp -lp on the nfs-mounted NAS area works fine, showing identical inodes indeed.

Question information

Language:
English Edit question
Status:
Answered
For:
Back In Time Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Joost 't Hart (joost-t-hart) said : 		#1

Reading my own text (weird problem indeed), I checked once more the details regarding the new files

1) The files (not the containing directories) are pretty old. 2008 or so, much older than the most recent rsync action. Should this matter?
2) The group membership of the files is different from other files in the backup set, as they happened to be copied from a left-over from an old machine. Careless me! Accessing them as owner (and the one who is executing the backup) on the local machine is not an issue, but the group of membership does not exist on the NAS. Probably as a result of that, I also cannot see these files from another win* box who is seeing the tree through samba. Still, should this matter?

Revision history for this message
Joost 't Hart (joost-t-hart) said : 		#2

Answer to both questions in my follow-up #1 is possibly "no," since <new folder> and all files underneath have ended up nicely in the 3rd snapshot which is under construction.

What's more: I can even see them sitting there from my win* box....

Revision history for this message
Joost 't Hart (joost-t-hart) said : 		#3

So I repeated the test by adding another directory with some files to the backup set. This time with the desired group id and permissions and all touched.

Everything went fine, leaving the hard links to unchanged material in place!

This adds another question to the equation:
"what (the whack) made rsync think it would be a good idea to delete all the unchanged files?" This is actually a serious (and dangerous I would say) bug, isn't it?

Thanks,
Joost.

Revision history for this message
Germar (germar) said : 		#4

Hi Joost!

First of all, is there any special reason for you to use NFS? Do you have SSH access to the remote host? If yes, I'd recommend using BIT with Mode SSH + 'Full rsync mode'. With NFS rsync behave like you're syncing to a local disk which will waste lots of bandwidth and time. Mode SSH is faster and more effective.

Regarding your Questions:
#0Q1 and #3) I've no clue what happened there. First time I thought it could've been a time difference in mtime. But that wouldn't result in deleting them, just resyncing.
May be the source is a removable drive which got unmounted (for what ever reason) during the snapshot? Just shooting into blue...

#0Q2) Yes, they will all be fresh copies. BIT will create hard-links only from last snapshot. If that is empty there will be no hard-links at all.

#1Q1) The age of the files doesn't matter.

#1Q2) You where using the old method ('Full rsync mode' deactivated) which will use 'cp -aRl' to create hard-links and stores user group and permissions in an extra file. In this case all files in your backup will be owned by the user/group who was running BIT and they will be read-only. So that doesn't matter either.

Can you help with this problem?

Provide an answer of your own, or ask Joost 't Hart for more information if necessary.

To post a message you must log in.