Comment 10 for bug 412470

Revision history for this message
Bart de Koning (bratdaking) wrote : Re: [Bug 412470] Re: hardlinking doesnt work from cronjob with schedule per included folder enabled

By the way I changed the name and the description a bit

2009/9/1 Bart <email address hidden>

> Some strange things I notice: your includes and excludes are a bit weird
> like:
> --exclude="/home/peter/BiTtest"
> --include="/home/peter/BiTtest/subfolder/**"
> Should not mention the exclude... oh wait it should mention it if the
> folder that should only be backupped once every year or something is a
> subfolder of a folder that should be backupped every 10 minutes, it should
> exclude it. And apparently it does not overwrite the includes -> it produces
> the snapshot with the files anyway
> So that makes sense
>
> What does not on the other hand is the cp -alb function for a folder it
> already copied, anyway, actually what is the whole reason for this command,
> ignored folders are copied anyway during the hardlinking?
>
> At the moment I am checking a quite difficult backup scheme to see if this
> behaviour is reproducable here. Probably some commands for the schedule per
> folder backup do the wrong thing.
> Ok, it is now making a snapshot and calls indeed the cp -alb command, it
> consumes loads of time. It even comes over the 10 minutes (the rsync took
> not more than 2 minutes) so it delays my next (hourly) backup. However it
> does do the right thing if the directories are disjoint. I will try to make
> an exclude that is joint...
> The backup dir has grown incredibly in size, however I do not see the ~
> behaviour yet. What I do see is time consumption, and size consumption. The
> hardlinking definitely fails when it does the small job (I have two
> schedules: 1 every 10 minutes, 1 every hour). The every hour job goes
> perfectly fine and as normal, but the 10 minutes job is behaving not as it
> should (actually right at this point it consumed all the space there was,
> filling up my logs with warnings, while there used to be plenty of space two
> hours ago when I started this test, it also did not rename or remove the
> new-snapshot folder any longer, -> another bug...)
> So far my main conclusion is that you should not use the schedule per
> included folder option as it is still buggy!
>
> Cheers,
> Bart
>
>
> 2009/8/31 Borph <email address hidden>
>
> I reproduced now the issue with the *~ files!
>>
>> I made two folders with two files each:
>> peter@borphtux:~$ ls /home/peter/BiTtest/
>> file1.txt file2.txt subfolder
>> peter@borphtux:~$ ls /home/peter/BiTtest/subfolder/
>> file3.txt file4.txt
>>
>> The schedule was:
>> /home/peter/BiTtest: every 10min
>> /home/peter/BiTtest/subfolder: every 5min
>>
>> The config file (part):
>> snapshots.exclude_patterns=*.backup*:/media:/lost+found:**/.thumbnails/**
>> snapshots.expert.per_directory_schedule=true
>>
>> snapshots.include_folders=/home/peter/BiTtest|4:/home/peter/BiTtest/subfolder|2
>>
>> I made a forced backup and got a "20090831-203106" folder with the
>> expected files.
>>
>> I changed file1 and file3 and waited. 20090831-204000 got created with
>> including both folders as expected.
>>
>> I changed again both files. 20090831-204500 got created with these files:
>> peter@borphtux:~$ ls -l
>> /media/BigBilly/System/BackInTime/backintime/20090831-204500/backup/home/peter/BiTtest/
>> insgesamt 12
>> -r--r--r-- 2 peter peter 11 2009-08-31 20:35 file1.txt
>> -r--r--r-- 4 peter peter 10 2009-08-31 20:28 file2.txt
>> drwxr-xr-x 2 peter peter 4096 2009-08-31 20:36 subfolder
>> (this is as expected, unchanged, but was not due)
>>
>> peter@borphtux:~$ ls -l
>> /media/BigBilly/System/BackInTime/backintime/20090831-204500/backup/home/peter/BiTtest/subfolder/
>> insgesamt 16
>> -r--r--r-- 2 peter peter 11 2009-08-31 20:36 file3.txt
>> -r--r--r-- 1 peter peter 12 2009-08-31 20:41 file3.txt~
>> -r--r--r-- 4 peter peter 10 2009-08-31 20:28 file4.txt
>> -r--r--r-- 1 peter peter 10 2009-08-31 20:28 file4.txt~
>>
>> Hum, these *~ files got created! During the next 10-min backup they
>> disappear, ok, but this means they come each time a subfolder is backed
>> up and a folder above not!
>>
>> Lets see the logfile:
>> INFO: Create hard-links
>> INFO: Command "cp -al
>> "/media/BigBilly/System/BackInTime/backintime/20090831-204000/backup/home/peter/BiTtest/subfolder"*
>> "/media/BigBilly/System/BackInTime/backintime/new_snapshot/backup/home/peter/BiTtest/subfolder""
>> returns 0
>> INFO: Call rsync to take the snapshot
>> INFO: Command "rsync -aEAX -v --delete-excluded --chmod=Fa-w,D+w
>> --whole-file --delete --exclude="/media/BigBilly/System/BackInTime"
>> --exclude="/root/.local/share/backintime"
>> --include="/home/peter/BiTtest/subfolder/" --include="/home/peter/BiTtest/"
>> --include="/home/peter/" --include="/home/" --exclude="*.backup*"
>> --exclude="/media" --exclude="/lost+found" --exclude="**/.thumbnails/**"
>> --exclude="/home/peter/BiTtest" --include="/home/peter/BiTtest/subfolder/**"
>> --exclude="*" /
>> "/media/BigBilly/System/BackInTime/backintime/new_snapshot/backup/"" returns
>> 0
>> INFO: Save permissions
>> INFO: Command "cp -alb
>> "/media/BigBilly/System/BackInTime/backintime/20090831-204000/backup/home/peter/BiTtest/"*
>> "/media/BigBilly/System/BackInTime/backintime/new_snapshot/backup/home/peter/BiTtest""
>> returns 0
>>
>> So I guess the second cp -alb copies the old version (the previous
>> snapshot) again over the new_snapshot. This explains the file-dates!
>>
>> Of course the cp -alb after the rsync is meant to copy hard-linked the
>> folders, which have not been synced. But if the folders are not
>> disjoint, this command includes recursively already synced files,
>> attempting to overwrite them.
>>
>> Last but not least:
>> peter@borphtux:~$ backintime -v
>> Back In Time
>> Version: 0.9.26
>>
>> --
>> hardlinking doesnt work from cronjob with schedule per included folder
>> enabled
>> https://bugs.launchpad.net/bugs/412470
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>