resume an extract operation

[ThomasWaldmann]

in master (borg 1.1), borg create has quite nice in-file checkpointing abilities, so you can even backup huge files over instable connections.

but if you want to extract such a huge file over a instable connection, it might break down before completion and there is no resume yet.

there are 2 cases:
a) a bunch of files has already been extracted (each file complete, but not all files you want)
b) extraction of a huge file breaks down in the middle

[ThomasWaldmann]

note: somehow this is a special case of "updating a local directory" so it afterwards looks like the extracted archive's contents (IIRC we have a ticket for that).

[ThomasWaldmann]

with PR #1217 one gets a workaround for restoring huge files over bad connections: if getting the file in one go does not work due to connection breakdowns, one can use borg extract --consider-part-files and extract one part file after the other. After one has all the parts, one can just concatenate them to get the full file.

Update: part files are gone in borg2.

[akvadrako]

I have been testing my backups today and having a lot of trouble running "borg extract" even with rather small archives (1GB) hosted on borgbase. Although it would be good to fix the root cause, having a continue / resume feature would be very helpful.

[aquada]

A possible workaround for this could be to mount the repo and then use rsync to copy the files.

[svenb1234]

I guess there is still no argument to extract to skip exisiting files and continue extraction where it aborted?

[ThomasWaldmann]

@svenb1234 no and it's not that easy anyway (e.g. the previous extract could have aborted in the middle of a file).

[svenb1234]

My thought was that one checks whether the file exists. If so, check the date whether it's the same, then check the size whether it's the same, then check the checksum. If any of those is not equal, replace the whole file or create it.

[ThomasWaldmann]

@svenb1234 good idea (except that we do not have a full-file checksum, just the list of chunkids - so one would need to re-chunk / re-hash the local file to verify against these. but guess if all metadata is the same, we can assume that the file is the same also).

do you want to implement that / make a PR?