I first did a search on both the forum and within the documentation and couldn’t find a canonical answer:
Question: What’s the recommended/prescribed way to back up system-level filesystem paths? Specifically, I’m interested in backing up /etc (on a Linux system) to preserve system configuration (as well as my changes, where applicable).
Context
I have a Linux system with a single administrative user. I primarily use kopia snapshot create $HOME to back up /home/user, where obviously, there aren’t any permission issues. This works great!
However, as stated above, I’d like to now monitor path /etc too to track system configuration changes. Obviously, these paths are owned by root.
I’ve tried the following:
Normal kopia snapshot create /etc invoked as my user. This spits out a bunch of fatal permission errors.
sudo kopia snapshot create /etc.
sudo su to change to the root user, then I connect to the repository as a different (root) user, then kopia snapshot create /etc.
Scenario 1 doesn’t work well because a large portion of the path is untracked due to permission errors, largely negating the benefit of a backup in the first place.
Scenarios 2 and 3 seem to work well at first, but then I later get permission errors when I return to “normal usage” as a non-root administrative user.
I’m assuming that, if I always prefix any Kopia command with sudo, I wouldn’t run into any permission issues… and I suppose, upon restore, I could chown data back to it’s “rightful owner”… but my question would then be, is this a good idea? It certainly wouldn’t be my preference (feels “dirty”) if there’s a better way that I’m missing!
I’m assuming you’re snapshotting to a local filesystem. This will mean that the blobs will be saved as root which will create the issues you are experiencing. You could set acl’s to ensure default privileges for a backup group allows read/write.
You’ll need to check this, as it’s from memory, but something like:
Having said the above, I normally use root for backups. Whilst it is no doubt considered not ‘best practice’, it’s my opinion that backups are the domain of a super user to avoid permission issues. You’re going to have to grant some user access to ‘everything’ anyway, so reducing the number of fully privileged accounts outweighs the downside (IMO).
Practically any Windows backup solutions running under administrative account, just for the reason to backup everything, form all users. The same with Unix world, if you want to backup all data, run kopia directly as root (with no sudo), so it will backup all users and their data. To be make sure local users won’t try to exploit kopia (and saved logs, cache, and especially config with backup password), set on kopia file permission 700, so the only root will have rights on backup solution.
To be make sure you backing up all metadata, use in kopia’s action hook just before taking snapshot run getfacl(1) to archive also all extra file/directory attributes. In case of restoration, you restoring files and run then setfacl from previously saved file.
Also, if there are some very important data, you can utilize proven by time principle of “checks and balances”. While kopia already has mechanism to verify data, you might want to save also extra integrity information with utilities like mtree (or gomtree) that also hashs data and run it again after restoration to be make sure there wasn’t any bitrots.
For even more paranoiac cases one might want to have multiple backup repositories and for most important data even utilize par2 utility that can restore broken data by saving some extra restoration information.
Let get back back to the user that would run kopia, you shouldn’t trust from the point of backup even root. Assume you got a virus or there was 0-day vulnerability (that gain root access) and bad actors used it or some smart ransomware… in these cases all backups either would be deleted or encrypted with unknown key. For this reason, one should have dedicated machine that used for backup purpose which accepts backup snapshots in APPEND mode (kopia there must run in server mode) from registered and restricted kopia’s users (which you creating with kopia server acl add --user=USER --target=TARGET --access=ACCESS).
I disagree here. “best practice” can’t cover all use cases and backup procedure is defiantly out of scope of such “best practice”. There’re bunch of processes running as root user with that exact reason to do the job that regular/restricted users must not do. Running critical processes as root guarantee separation from regular, restricted user(s) and allow to backup all users metadata where dedicated backup user won’t do that for sure. That’s exact case where “best practice” will be to run backup process only as the root, to be sure that one of the most important process as backup don’t run as regular user than might be compromised.
The problem with setcap is that you have to remember to set capability after each upgrade of kopia, otherwise new version will lost assigned extended attribute.
Use can use setcap on the kopia binary to gain read permissions on all files. Take a look at the example in restic’s documentation
Is this the best way to do it? I want to make a script that automatically backups my /home /etc /usr /opt and use either cronie or systemd to make it run every 15 or 30 minutes. I have gotten everything working just right when it’s just my ~/home being backed up. I use “PASS” to store the reop pwd.
I can’t say I follow the steps on the restic documentation (I’m a noob) so if somebody understands that
could you please educate me on the setup process, tee-spoon approach?
and how would you restore files and folders back to your main user?
How do you guys handle the passwords for the repos if you use it in automated backup scripts?
How would you do periodic and random file integrity checks?
if you have a script that works for both privilege filesystem paths and none, or run everything as privilege and could share it (with removed sensitive information of course) I would highly appreciate it and I’m sure I’m not the only one.
what I want to use these backups for besides disaster recovery if that ever happened, would be to get quickly back up and running again on a different system, or just reinstalling the distro or jumping distros. and get back to where it was so to speak.
-edit:
What I primarily don’t understand is:
why are the new user being created in the /sbin/nologin dir?
what does this mean setcap cap_dac_read_search=+ep I could not find it in --help
how would the command be for creating and connect to a repository on an external SSD?
How would the command be for creating and mounting a snapshot be?
would I have to install kopia again with it in the ~kopia/bin folder?
Is this the best and easiest way to do it? I cannot figure out how to make my bash script run as Root/sudo to be able to back up /etc /usr /opt like OP mentions. I have some questions regarding the setcap and what is being done in the restic documentation.
Hopefully someone can explain it to me since I’m a newbie.
- why is the new user being created in /sbin/nologin kopia? (in our case)
- How would we (kopia) use the curl -L command?
- What does this mean ``` setcap cap_dac_read_search=+ep ```
- What would be the command to create and [dis]-connect to our repository?
- What would be the command to create and check snapshots?
- What would be the command to restore whole snapshots or/and mount snapshots for GUI restoration of files and folders?
- I would highly appreciate it if someone could educate me on this
I guess I should have clarified a little better. but did not want to highjack this post for this.
do you store your sudo and repository passwords in plaintext in the script as well to be able to run it automatically in the background?
That’s just a convenient one-liner to download and extract the binary. The point is to make sure you have a dedicated binary for this task which no one else can execute.
It adds permission to read privileged files. See the man page for capabilities for more information on this topic.
The commands are the same - please consult the documantion for details. Note that you do not need to add privileges with sudo in this case, as the binary already has enough privileges to read all files. And you need to make sure that you are using the correct binary in case you have more than one installed.
I’m following the restic documentation, but I get an error when trying to use the curl command, everything is run as root
curl -L https://github.com/kopia/kopia/releases/download/v0.10.7/kopia-0.10.7-linux-x64.tar.gz | tar -xzvf > ~kopia/bin/kopia
curl -L https://github.com/kopia/kopia/releases/download/v0.10.7/kopia-0.10.7-linux-x64.tar.gz | tac | tac | tar -C ~kopia/bin/kopia -zxv(f)
no-matter which one I try ^ I always get an error
tar: option requires and arguemtrn -- 'f'
(if I use the "-zxvf" option)
tar: /home/kopia/bin/kopia: Cannot open: Not a directory
tar: Wrror is not recoverable: exiting now
(if I use the "-xzv" option)
Even if I download the https://github.com/kopia/kopia/releases/download/v0.10.7/kopia-0.10.7-linux-x64.tar.gz manually first, the run the
tar -C ~kopia/bin/kopia -xzv(f) kopia-0.10.7-linux-x64
I never get the anything in the ~kopia/bin/kopia so I cant install kopia with go
Does anyone have any solutions to this? or could one of you that are smarter than me re-write the restic documentation for kopia and arch if the distribution have anything to do with it?
When I eventually get this figure out I will make a YT tutorial on how to do this so that other people won’t have the same struggles as me.
After f one should use a filename according to manual (man tar) and since you piping to tar the file will be -
Let me offer you an easier solution:
wget https://github.com/kopia/kopia/releases/download/v0.10.7/kopia-0.10.7-linux-x64.tar.gz && tar xvf kopia-0.10.7-linux-x64.tar.gz kopia-0.10.7-linux-x64/kopia
then in the directory kopia-0.10.7-linux-x64 you will find kopia
Also, my advise would still be the same, do not mess with setcap utility, such tool shouldn’t be use by copy/paste from “how-to” directions if you don’t understanding kernel’s capabilities. Just use kopia under the root account, it won’t do any harm to your computer, just be sure you choose correctly target directories for backup and you good to go
