You could just have a dedicated backup user that is in all the groups of you docker volumes.
this post was submitted on 26 Nov 2023
14 points (88.9% liked)
Selfhosted
40113 readers
1062 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
This is a common strategy in enterprise, they're called Service Accounts.
Rather than let all services/apps run under one admin account (windows) or a single account with root (*Nix), an account is created for each service/app, with only the minimum necessary permissions. These accounts are also limited, sometimes they're local accounts on a given server (rather than a domain/directory account), usually with no login capability (so couldn't run in a user context).
This way you prevent a 3rd party service/app from having change access to other services/apps (in Windows services run as system by default, a terrible security hole). It also prevents a rogue admin from using such access to change other things (or if the service account credentials were stolen).
This might be a good idea. It would only work for files that allow read access for the group, but that should be fine
Add the DAC_READ_SEARCH capability to the restic binary (using setcap).This is what allows to read all files. Obviously this means being able to read all, all, files including shadow etc.
This is a great hint, thank you. I just discovered that the official restic docs recommend this method too
Thank you!
Oh that's good to see! Sorry if I didn't expand much before, I was writing from my phone.
Good luck :)
You didn't mention how big those volumes are and how frequently the data changes.
Assuming it's not that much data:
- use
tarto archive each volume first, while using proper options to preserve permissions and whatever else is important for your usecase - use restic to backup those archives
- use a proper pruning strategy to not let your backups get too big:
- I'm not that familiar with
restic, but maybe you can backup those archives separately and apply a more aggressive pruning strategy just for them - simply might be needed, cause deduplication (AFAIK) might not be that great with backing up archives
- but maybe if the volume data and the resulting archive doesn't change that often, deduplication would be sufficient even with a not so aggressive pruning strategy
- I'm not that familiar with
Restic uses smart Delta backups, creating a tar before the restic process would defeat the purpose. The permission issue is the same, as I need to have access to the Files either way.