[Borgbackup] VM backup issues

Thomas Waldmann tw at waldmann-edv.de
Thu Nov 16 12:51:31 EST 2017


> 1) After looking at the some of the code, I realized that the 
> --read-special is not doing what I thought it would do.

Well, it is special. :D

The files-cache related stuff applies to regular files, not to block 
devices (or other stuff processed by --read-special).

> 2) When I create a backup my VM, I create a temp directory, symlink the 
> VM block device as well as some regular files. I also symlink any file 
> based images related to the VM (ie; .img or .iso). I am finding that the 
> other non block files are only backing up the symlinks. How do I get it 
> to backup the file, not the symlink?

Use a hardlink?

> 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.

> 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?

> *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.

> *: [Errno 2] No such file or directory: '*'

Normal behaviour. It has trouble to open that "file", emits a warning 
and continues (and then it finds there is nothing more to do).

> 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.

> It returned an rc of 1, did not backup any files, but it created an 
> entry as if the backup was complete. Why was this a problem? Because 
> above when I use the 'borg list --json --last 1' to see when the last 
> backup was done, it appears a backup was done when it really wasn't. 
> Make sense?

I see your problem, but the solution is not borg deleting the archive it 
began if it ends up writing nothing to it, but rather that you check if 
the borg command returns with rc != 0 and fix whatever the issue was.

-- 
GPG Fingerprint: 6D5B EF9A DD20 7580 5747  B70F 9F88 FB52 FAF7 B393
Encrypted E-Mail is preferred / Verschluesselte E-Mail wird bevorzugt.


More information about the Borgbackup mailing list