[Borgbackup] VM backup issues

[Ken Bass]

On 11/16/2017 12:51 PM, Thomas Waldmann wrote:
>
>> I am having to resort to bind mounting non-block device files because 
>> of this. Is this the only solution?
>
> If hardlinking does not work, yes.

Hardlink is not reliable because it doesn't not work across file system 
boundaries.

>
>> 3) Because of the chunking issue, I took a different approach. I 
>> wrote a wrapper that first does a borg list --json --last 1 to parse 
>> the archive 'start' time. I am assuming this tells me the time of the 
>> most recent backup. I then check, via os.stat, if any of the VM 
>> related images have been modified since them (I am using mtime).
>
> You are using mtime of a regular (disk image) file or the LVM device 
> file?
Both depending on what the underlying file is... os.stat following 
symlinks will indicate that the mtime of either. That appears to be what 
I want.

>
>> *I think I found a bug doing this*. I created my tmp directory and 
>> os.chdir() into it. I was using 'borg create ... *' via a 
>> subprocess.check_output(). I think due to safety checks, the '*' was 
>> passed literately rather than globbing.
>
> If you don't use a shell, there won't be a shell that expands wildcards.
> And on UNIX, it is the job of the shell to expand commandline 
> arguments, except if you quote them.

Correct - it was just a typo on my part, I should have used 
'glob.glob('*')' but I thought the result was inconsistent - making an 
empty backup. In fact is seems downright dangerous to proceed with an 
empty backup. If someone were to do a prune afterwards they could 
potentially wipe out their last good backup depending on how many they 
are keeping.

> Number of files: 0
>> terminating with warning status, rc 1
>
> Hmm, there might be some check if a given path did not match anything 
> at all and then sets warning status for the rc code.
I don't really know what it is supposed to do. I consulted the man page 
for borg and the entirety of the 'Return codes' section is:

        Borg can exit with the following return codes (rc):

        If you use --show-rc, the return code is also logged at the 
indicated level as the last log entry.

There is no description of what any of the returns code are. I would 
have thought a non-zero meant a backup was not made/failed, but that was 
obviously not the case. Of course I have corrected my typo since, but 
still think it is dangerous to make an empty backup like that. I was 
thinking maybe it would have treated it as an aborted backup that didn't 
complete or something, but not a completed one.