could rsbackup have a mollyguard check that device-id is actually at the root of a filesystem? #42
Labels
Milestone
Comments
|
Yes, I think this is a good idea. |
ewxrjk
added a commit
that referenced
this issue
Feb 16, 2018
--store now has the same behavior as the 'store' directive: the store must be a mount point. --unmounted-store allows store directories that aren't mount points. As well as providing an escape hatch to the previous behavior we need this for testing. re #42
ewxrjk
added a commit
that referenced
this issue
Jul 27, 2018
This can be disabled with new options to store and store-pattern. fixes #42
ewxrjk
added a commit
that referenced
this issue
Jul 27, 2018
--store now has the same behavior as the 'store' directive: the store must be a mount point. --unmounted-store allows store directories that aren't mount points. As well as providing an escape hatch to the previous behavior we need this for testing. re #42
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi; this is a wishlist suggestion based on a user error I made this week bringing a new backup disk into service. Basically when I created the "device-id" file I forgot to actually mount the backup disk first. The result was that rsbackup happily started to back the machine's root disk up to a subdirectory of itself, until it ran out of disk space.
Would it be possible/sensible for rsbackup to complain if the directory with device-id isn't actually a filesystem root? (I guess you'd want an override for people doing odd things, but the 99% usecase is presumably that it should be the fs root.)
The text was updated successfully, but these errors were encountered: