You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Enhancement]: Support read-only volumes for local filesystem directory source without failed state (healthchecks) #200
The non-configurable health-checks are working (trying to work) in .dbackup directory created in the source location
(I assume with a scheduled touch to see if the location can be marked healthy)
They will obviously fail, if the volume is mounted as read-only and marking the source as offline (but still operational)
Proposed Improvement
Make the actual healthcheck optional for source local filesystem types
Have some sort of "unknown" or "uncertain" status for such a scenario (when the health intentionally cannot be verified, but its not confirmed unhealthy)
Check if the directory is located on a RO volume when its being created/configured and propose disabling healthchecks for it (major change, not expecting this at all, just throwing in ideas)
Motivation
Allowing the use of read-only volumes without failed state and reducing unnecessary health-checks that will 100% fail all the time
Ah, so it's about the state itself. But “Read Only” doesn't make any sense for a directory source or destination, does it? Or am I misunderstanding something?
I was considering both the state itself, and unnecessary attempts to write to a location that'll always fail. (I know its a minor thing, but still)
Just to clarify, I have a location where I keep all my persistent data for my docker containers. I've mounted that location as a read-only volume into DBackup, so it can access SQLite databases and the files to do the backup, using the local storage setup.
I would never want to restore to these locations directly, so read-only is making sure data could never be actually written here. Only read, as a source for the backups.
The solution is perfectly functional, it is just a minor inconvenience the connections are marked as offline :)
I figured it'd be a niche case, if the healthcheck could be enabled/disabled for the local filesystem type if its a source, I think that'd make the most sense. (Like the alerts on your screenshot)
I'm using a bunch of other database types and storages as well, so I like the health-checks in general, I wouldn't want to lose them completely!
Activity
Skyfay commentedon Oct 14, 2026
Hey @arkangelll13
You can disable health checks for each database, directory source, or destination.
Is this what you are looking for?
Skyfay commentedon Oct 14, 2026
Ah, so it's about the state itself. But “Read Only” doesn't make any sense for a directory source or destination, does it? Or am I misunderstanding something?
arkangelll13 commentedon Oct 14, 2026
I was considering both the state itself, and unnecessary attempts to write to a location that'll always fail. (I know its a minor thing, but still)
Just to clarify, I have a location where I keep all my persistent data for my docker containers. I've mounted that location as a read-only volume into DBackup, so it can access SQLite databases and the files to do the backup, using the local storage setup.
I would never want to restore to these locations directly, so read-only is making sure data could never be actually written here. Only read, as a source for the backups.
The solution is perfectly functional, it is just a minor inconvenience the connections are marked as offline :)
Skyfay commentedon Oct 14, 2026
Thanks for clarifying. This is a usecase i never thought about. I'll think of a solution. Probably just disable it completely for certain adapters.
Or, if you only have Read Only and only SQLite, you can simply disable the health checks entirely in the System Tasks section of the settings.
Would that be a solution, too?
arkangelll13 commentedon Oct 14, 2026
I figured it'd be a niche case, if the healthcheck could be enabled/disabled for the local filesystem type if its a source, I think that'd make the most sense. (Like the alerts on your screenshot)
I'm using a bunch of other database types and storages as well, so I like the health-checks in general, I wouldn't want to lose them completely!