backup of available paths should not fail - if other paths are missing

[goebbe]

Testing vykar 0.12.14 with the following sources.

sources:
  - label: home
    paths:
      - /home/goebbe
      - /testfolder/subfolder1

If I try to do a backup, however, the whole backup fails, when the second path is not available:

$ vykar
--- Repository: NAS ---
==> Starting backup
 WARN recovered pending index entries from interrupted sessions recovered_chunks=1 journals=1
Files: 10795, Original: 11.11 GiB, Compressed: 8.95 GiB, Deduplicated: 0 B, CurrFiles: 21229, Original: 24.59 GiB, Compressed: 17.75 GiB, Deduplicated: 0 B, CurFiles: 33623, Original: 35.98 GiB, Compressed: 23.17 GiB, Deduplicated: 0 B, CurFiles: 44760, Original: 40.82 GiB, Compressed: 23.98 GiB, Deduplicated: 0 B, Cur WARN saving progress for next run…
Files: 49894, Original: 40.89 GiB, Compressed: 24.01 GiB, Deduplicated: 0 B, Current: 
Error: source directory does not exist: /testfolder/subfolder1: No such file or directory (os error 2)
==> Starting prune
==> Starting compact
==> Starting check

Expected behaviour:

• Warn about the missing paths
• Do a backup of the existing paths

[m3nu]

Warn about the missing paths

I think if top-level paths are missing this should be an error, not a warning. For backups the principle should be to error out sooner. If the user misses the warning he may miss the backup of his files.

[goebbe]

O.k. I came from a different direction, here.
When I was testing/ exploring ways to "reinclude" certain folders, I also experimented with the
use of paths (to reinclude a folder) or hooks.

For the hooks only, a famous Vykar developer commented:
"Looks a little fragile. If one folder is missing the whole backup stops working."
#27 (comment)

This was the reason I was opening this issue here - since the same reasoning applies to a missing path:

If a reinclude solution via hooks is "fragile", if it stops working when a folder is missing,
then the same would apply
to a reinclude solution via paths. I.e. it would be "fragile" if it stops working when the path is missing.

To make a long story short: Feel free to close this issue.

Vykar should encourage the use of reinclude rules (.gitignore) for this very purpose.
Paths are main building blocks of backups - throwing errors if a path is missing makes sense.

[m3nu]

My memory is short, so I don't remember this comment. 😅

I've had situations where a backup was incomplete due to the 'one filesystem' option because the mount setup of a NAS changed after an update. So I'd rather see it fail. When thinking about it. But there are arguments for both.

[goebbe]

I think it really comes down on how you use Vykar:

• If you are notified about errors - you probably want to throw an error if a path is missing - so you could check/ fix it.
• If you are NOT notified about errors (or miss it) - there are no backups - even for the paths that exist.

I guess making a backup for the existing paths first - and throwing an error for the missing paths afterwards is not a feasible solution?

[m3nu]

Let's think about it more and also compare with how other tools do it.

[celogeek]

on kopia, it skip backup of missing directories if scheduled, like external drive. When you plug it in, then the next try succeed.
You also have a notification that the automatic backup failed.