# Recommended way to back up privileged filesystem paths?

**URL:** <https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200>\
**Category:** Support\
**Created:** [June 8, 2022, 3:33pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200 "2022-06-08T15:33:25Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![dsimmons](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dsimmons/32/218_2.png) [@dsimmons](https://kopia.discourse.group/u/dsimmons)\
**Post date:** [June 8, 2022, 3:33pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/1 "2022-06-08T15:33:25Z")

</div>

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:

1. Normal `kopia snapshot create /etc` invoked as my user. This spits out a bunch of fatal permission errors.
2. `sudo kopia snapshot create /etc`.
3. `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!

---

<div class="post-metadata">

**Author:** ![Matt](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@Matt](https://kopia.discourse.group/u/Matt)\
**Post date:** [June 9, 2022, 4:45am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/2 "2022-06-09T04:45:38Z")

</div>

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:

```auto
sudo groupadd backup
sudo usermod -a -G backup myuser
sudo chown -R myuser:backup /path/to/repo
sudo chmod g+s /path/to/repo
sudo setfacl -d -m g::rwx /path/to/repo
sudo setfacl -d -m o::rx /path/to/repo

```

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).

---

<div class="post-metadata">

**Author:** ![iBackup](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/ibackup/32/355_2.png) [@iBackup](https://kopia.discourse.group/u/iBackup)\
**Post date:** [June 9, 2022, 7:07am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/3 "2022-06-09T07:07:04Z")

</div>

> [@dsimmons](#):
>
> I could `chown` data back to it’s “rightful owner”… but my question would then be, is this a good idea?

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.

> [@dsimmons](#):
>
> if there’s a better way that I’m missing!

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`).

---

<div class="post-metadata">

**Author:** ![iBackup](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/ibackup/32/355_2.png) [@iBackup](https://kopia.discourse.group/u/iBackup)\
**Post date:** [June 9, 2022, 7:22am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/4 "2022-06-09T07:22:32Z")

</div>

> [@Matt](#):
>
> Whilst it is no doubt considered not ‘best practice’

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.

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [June 9, 2022, 10:02am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/5 "2022-06-09T10:02:54Z")

</div>

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](https://restic.readthedocs.io/en/stable/080_examples.html#backing-up-your-system-without-running-restic-as-root).

---

<div class="post-metadata">

**Author:** ![iBackup](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/ibackup/32/355_2.png) [@iBackup](https://kopia.discourse.group/u/iBackup)\
**Post date:** [June 9, 2022, 2:58pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/6 "2022-06-09T14:58:31Z")

</div>

> [@dimejo](#):
>
> Use can use `setcap` on the kopia binary

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.

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [June 9, 2022, 4:07pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/7 "2022-06-09T16:07:25Z")

</div>

> [@iBackup](#):
>
> 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.

There is always a tradeoff between flexibility, simplicity and security. 😉

---

<div class="post-metadata">

**Author:** ![iBackup](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/ibackup/32/355_2.png) [@iBackup](https://kopia.discourse.group/u/iBackup)\
**Post date:** [June 9, 2022, 7:59pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/8 "2022-06-09T19:59:39Z")

</div>

> [@dimejo](#):
>
> There is always a tradeoff between flexibility, simplicity and security

That is real truth ! 🙂

---

<div class="post-metadata">

**Author:** ![av8r](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@av8r](https://kopia.discourse.group/u/av8r)\
**Post date:** [June 10, 2022, 10:40pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/9 "2022-06-10T22:40:17Z")

</div>

> 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?

---

<div class="post-metadata">

**Author:** ![av8r](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@av8r](https://kopia.discourse.group/u/av8r)\
**Post date:** [June 11, 2022, 6:13pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/10 "2022-06-11T18:13:18Z")

</div>

My previous post/question got taken down for now good reason so I’ll try again, because I want to learn.

> Preformatted text`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](https://restic.readthedocs.io/en/stable/080_examples.html#backing-up-your-system-without-running-restic-as-root).

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.

````auto
- 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

````

---

<div class="post-metadata">

**Author:** ![Matt](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@Matt](https://kopia.discourse.group/u/Matt)\
**Post date:** [June 12, 2022, 7:33am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/11 "2022-06-12T07:33:49Z")

</div>

> [@av8r](#):
>
> 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.

You just call it with `sudo`. EG

```auto
sudo /path/to/my/bash/script.sh

```

And it will run as root. Make sure your user is in the wheel group to allow them to use `sudo`.

---

<div class="post-metadata">

**Author:** ![av8r](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@av8r](https://kopia.discourse.group/u/av8r)\
**Post date:** [June 12, 2022, 1:58pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/12 "2022-06-12T13:58:22Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Matt](https://avatars.discourse-cdn.com/v4/letter/m/a6a055/32.png) [@Matt](https://kopia.discourse.group/u/Matt)\
**Post date:** [June 13, 2022, 10:03am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/13 "2022-06-13T10:03:10Z")

</div>

If it’s owned as root, and the file permissions are properly setup, anything inside the script is suitably protected from any other user.

You could run the script as an `at` job which eliminates the need to run under `sudo`.

---

<div class="post-metadata">

**Author:** ![av8r](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@av8r](https://kopia.discourse.group/u/av8r)\
**Post date:** [June 13, 2022, 8:47pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/14 "2022-06-13T20:47:45Z")

</div>

> You could run the script as an `at` job which eliminates the need to run under `sudo`

could you please post a link to what a `at` job is? or explain that to me? I have not heard of that before.

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [June 14, 2022, 8:23am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/15 "2022-06-14T08:23:45Z")

</div>

> [@av8r](#):
>
> - why is the new user being created in /sbin/nologin kopia? (in our case)

To create a definitive user just for backups.

> [@av8r](#):
>
> How would we (kopia) use the curl -L command?

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.

> [@av8r](#):
>
> What does this mean `setcap cap_dac_read_search=+ep `

It adds permission to read privileged files. See the [man page for capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html) for more information on this topic.

> [@av8r](#):
>
> - 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?

The commands are the same - please consult [the documantion](https://kopia.io/docs/) 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.

---

<div class="post-metadata">

**Author:** ![av8r](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@av8r](https://kopia.discourse.group/u/av8r)\
**Post date:** [June 19, 2022, 7:04pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/16 "2022-06-19T19:04:17Z")

</div>

> [@dimejo](#):
>
> 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.

Where do I find the URL for kopia for this curl -L command?

---

<div class="post-metadata">

**Author:** ![dimejo](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/dimejo/32/287_2.png) [@dimejo](https://kopia.discourse.group/u/dimejo)\
**Post date:** [June 20, 2022, 7:19am UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/17 "2022-06-20T07:19:15Z")

</div>

> **[Releases · kopia/kopia](https://github.com/kopia/kopia/releases)**
>
> Cross-platform backup tool for Windows, macOS & Linux with fast, incremental backups, client-side end-to-end encryption, compression and data deduplication. CLI and GUI included. - kopia/kopia

---

<div class="post-metadata">

**Author:** ![av8r](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@av8r](https://kopia.discourse.group/u/av8r)\
**Post date:** [June 21, 2022, 3:03pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/18 "2022-06-21T15:03:05Z")

</div>

I’m following the restic documentation, but I get an error when trying to use the curl command, everything is run as `root`

```auto
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

```auto
tar: option requires and arguemtrn -- 'f' 
(if I use the "-zxvf" option)

```

```auto
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

```auto
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.

---

<div class="post-metadata">

**Author:** ![iBackup](https://yyz2.discourse-cdn.com/free1/user_avatar/kopia.discourse.group/ibackup/32/355_2.png) [@iBackup](https://kopia.discourse.group/u/iBackup)\
**Post date:** [June 21, 2022, 10:08pm UTC](https://kopia.discourse.group/t/recommended-way-to-back-up-privileged-filesystem-paths/1200/19 "2022-06-21T22:08:55Z")

</div>

> [@av8r](#):
>
> `tar: option requires and arguemtrn -- 'f'`

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:

```auto
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