Better email message when resuming is not possible

[deajan]

I have one of my burp servers (currently 2.1.24, no encryption envolved), which has a very strange behavior.
I've setup a burp client 2.1.24, using protocol 1.
Begun backup of the client, had an interruption (user turned off computer).
Had about 30Mb of data in the working directory.
In order to finish the initial backup, I temporary changed the timer_arg, and noticed that I had an . incexc/std_settings line twice, so I removed one of the two lines.

On next timed backup, I got an error message via notify script stating error in check_for_rubble()
Checked logs on the server, got the following:

Feb 15 11:24:01 FDCFLXB01P burp[2647]: Connect from peer: xx.xx.xx.xx:53126
Feb 15 11:24:01 FDCFLXB01P burp[2647]: 0/500 child processes running on port 4971
Feb 15 11:24:01 FDCFLXB01P burp[2647]: Child 1 available
Feb 15 11:24:01 FDCFLXB01P burp[2647]: forked child on port 4971: 55775
Feb 15 11:24:02 FDCFLXB01P burp[55775]: auth ok for: client.some.pc.local
Feb 15 11:24:02 FDCFLXB01P burp[55775]: Client client.client.some.pc.local does not want a certificate signed
Feb 15 11:24:02 FDCFLXB01P burp[55775]: SSL is using cipher: DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
Feb 15 11:24:02 FDCFLXB01P burp[55775]: Server is using protocol=1
Feb 15 11:24:03 FDCFLXB01P burp[55775]: Client supports being sent json counters.
Feb 15 11:24:03 FDCFLXB01P burp[55775]: found old working directory: /burp/PROTOCOL1/client.some.pc.local/0000001 2018-02-13 10:46:52 +0100
Feb 15 11:24:03 FDCFLXB01P burp[55775]: working_dir_recovery_method: resume
Feb 15 11:24:03 FDCFLXB01P burp[55775]: Logging to /burp/PROTOCOL1/client.some.pc.local/0000001 2018-02-13 10:46:52 +0100/log
Feb 15 11:24:03 FDCFLXB01P burp[55775]: MESSAGE: Running notify script: client.some.pc.local  error in check_for_rubble()  backup 0 sendmail -t To: my@adress.com From: burp Server Subject: %b failed: %c %w Content-Type: text/plain; charset=utf-8
Feb 15 11:24:03 FDCFLXB01P burp[55775]: /usr/share/burp/scripts/notify_script returned: 0
Feb 15 11:24:03 FDCFLXB01P burp[55775]: exit child
Feb 15 11:24:03 FDCFLXB01P burp[2647]: pipe from child: end of data
Feb 15 11:24:03 FDCFLXB01P burp[2647]: pipe from child: disconnected fd 5

Then I tried to check the logs in the backup directory itself and....
Nothing's there. directory 0000001 2018-02-13 10:46:52 +0100 exists but is empty. symlink working exists too.
I am absolutely sure there were about 30MB of data some minutes ago.
Double checked my mountpoints. No problem, also my other clients datas are there so I think there isn't any storage probem.

Since I had a double . incexc/std_settings argument, I can only think of aborting a "resume" backup since some option line may have changed (doubt, since the incexc line was simply referring to the same file).

Anyway, burp deleted my incomplete backup here.
I can't produce more logs since I don't have any.
Next run removed the previous backup directory and created new one, working right now.

I've already searched the mailing list about this, but didn't find any answer.

[grke]

Hello,

If your includes/excludes changed since the beginning of the interrupted backup, burp deletes the interrupted backup and starts again.

It cannot resume and add any differences, because ordering matters.
It cannot resume and delete things that you have now decided not to backup, because that is too hard for me to code.

The choices are either:
a) Start again and backup everything that the user asked it to backup, or
b) Resume using the previous incexc settings and do not backup everything that the user asked it to backup.

Which do you think is better behaviour?

[grke]

I think I chose (a) originally, because there was originally no feature where the includes/excludes could be set from the server side. But now, it is probably possible to do (b). I don't know if it is the correct thing to do though.

[deajan]

Well that's the point, includes / excludes shouldn't have changed since they just were "doubled".
I know the changed behavior which forces full backups, which I think is right.

What bugs me here is the rubble error. If somehow even doubled exclude arguments can delete the current non finished backup, I'm fine with the error.
But I thought the rubble error (whatever it is) deleted the backup.

[grke]

Yes, doubled arguments can delete the unfinished backup, and then generates the email.
Maybe I can think about making the email say something more accurate in this case.

[deajan]

Would be nice indeed :)

[grke]

I have added a new config in git master, ready for the next release:

notify_failure_on_backup_working_dir_deletion=[0|1]
On the next backup attempt after a backup was interrupted, it may not be possible to resume the previous backup. In this case (or if working_dir_recovery_method is 'delete'), the previous backup will be deleted. You may wish to be notified about this. The default is off.