How does Kopia respond when source folder is not mounted?

General
1

What does Kopia do when a folder selected for backup is either a) missing because it’s removable media, or b) empty because it’s the mountpoint for an unmounted volume?
I’ve not yet moved to Kopia. My current program makes a mess if I let it run w/o all sources mounted.
I have several source folders that are regular external USB removable media. As such they get mounted at /media/user/volumename. I also have multiple source folders that are optionally mounted file-systems. For example a LUKS encrypted volume I only mount when needed. And a couple NFS volumes that are the www folder of LAMP stack virtual machines for web-design. For the LUKS and NFS, the mountpoint folder always exists, but is empty if volume is not mounted. What will Kopia do when it finds the empty folder? Does it matter where the folder is? Is there a way to mark the source as removable? Thanks.

2

Kopia does not have a concept of removable sources.

To avoid creating snapshot not containing any data from such not available source you can:

  1. Use your OS features to make sure that mount point is no accessible for kopia user when not mounted. In such case kopia backup will fail.
  2. Use actions and write a script checking if source is available. If not then you can terminate all backup (simply return non zero and make sure that action is configured as must succeed).
2 Likes
3

This isn’t a direct answer as I’m also in the assessment phase. This may be of note to your use case. Kopia has a --before-folder-action swtich that can fire off a script. By the name of if I only presume it is exec before the snapshot.

It should be combined with --action-command-mode=essential . That will require the script must successfully execute before snapshot execution.

#!/usr/bin/env bash

# path to a known, permanent file within the volume
FILE="/media/$USER/$volName/$myFile"

# does the file exist on the path?
# throw an error (1) & exit if it isn't present
[[ -f "$FILE" ]] && exit 0 || exit 1

Create one shell script per ea. volume. This is conceptually similar to a keyfile in cybersecurity/authentication systems.

1 Like
4

I think I would have them excluded from the main / snapshot, so its not part of the main snapshot run at all, then have them as separate snapshots with pre-snapshot actions to determine for each if they are mounted or not (ie, if they have content or are empty dirs) and only run that particular snapshot when they do. Then fire off the main run and after that, loop over the nfs/luks dirs and based on content or not, run those "snapshot create"s or not.

1 Like
5

all: outstanding! Works for me! Thanks for the quick replies.
Far better than my current situation: where an empty source folder triggers a mass deletion. Between the mass deletion and next valid backup, I can of course restore from ‘deleted-files’, or use point-in-time restore, but it’s still ugly.

1 Like
6

Apologies; I thought that was implied by OP. If the intent was to instead ‘skip’ including the mount point(s) in a (massive, bulk) singular snapshot while they’re unmounted I hadn’t considered that scenario. I’m averse to conceptual ‘info silos.’

7

I’m grateful Kopia offers these options. At this point, I have only setup the most simple deployment possible: Windows client with single source of ‘Documents’.
This question is of course related to a more complex client.
It’s not clear to me yet whether I have three options, or only two:
a)
desired, but perhaps technically impossible: single ‘job’ / ‘snapshot’ / ‘backup’ (forgive me don’t yet know the terminology to use) that includes all sources. If any are missing, they are skipped and assumed to have not changed. Obvious technical question that arrises is: what does one get if they restore a snapshot taken when some sources were offline?
b)
When any source is missing, abort entire snapshot. Not desirable. Some optionally mounted volumes might remain offline for many months.
c)
Separate ‘Jobs’:
One for the soruces that are always mounted.
One job each for each removable and/or optionally mounted volumes.
And each is independently run / skipped if mounted or not.

For my case, the last solution seems the likely fit.
I’m assuming these will still all share the same Repo.
If 97b4958b055b cares to elaborate, what are the negatives of this information silo?

8

I would make a separate <queue/job/repository/whatever you want to call it/according to Kopia’s preferred terminology here> for the removable media. Just don’t mix them into an ‘all or nothing’ massive snapshot job/setup.

It’s removable media. If it was never designed to be permanently attached to the host system (eg: USB stick vs an internal SSD) then don’t treat it as part of the primary system.That shell script will help with ‘sanity checking’ there (again, one script per ea. volume’s snapshot queue/job).

Separate ‘jobs’ are the way to go, IMO. That’s how I do with my (currently non-Kopia) regiment.

1 Like