How snapshot restore works

Hello! I m new here and im finding this tool really great, truly the missing piece of software!

Now i was trying to learn a bit how this works, after reading the docs i started to play a bit with a dummy path

premise: Im running this on latest image as a container in an unraid installation

now i simulated a scenario in which i only got partial data loss (so some files still exist that also do exist remotely on the repository), now i understand you can restore to a different path /app/snap_id or to a tarball etc, but lets assume i want to restore straight in the source path

through the gui i would get this error, also by ticking “Continue on Errors” the missing file still does not get restored

from cli, instead the restore goes straight, putting back in place the missing files without any fancy flags added, now i see there is a huge behaviour mismatch here… first thing first is not clear if the cli restore with no flags added would also delete local files to match the remote or would only add the missing ones ( I can try this but tomorrow i will change the source to my actual nas and i need 100% confirmation about this ) secondly from gui as i understand there is no way to do this kind of restore, one should or mount and manually add the missing ones or restoring in a different path (with the risk of downloading TBs of data), yes you can download one by one but gets really tedious when there are a ton of small files

now i would only like some confirmation about what i said, i discovered kopia yesterday and if this is the situation i will always go with cli restore

ot: i would like to ask a tiny info here even if slightly ot, i did not understand so much about where the configs are stored since to my understanding they are both stored locally and remotely, now i dont want too technical info about this i would only like to know: lets assume i would have a fresh kopia installation and/or lose my local appdata by remembering my repository password and obviosuly by still having my repository access credentials will i manage to restore everything? I also need to know this to understand if kopia local appdata would be a single point of failure and need a better backup strategy.

Thank you all in advance :slight_smile:

this is the gui error (i could upload only one media)

Re restore. GUI is limited indeed. To have full control use CLI and then you can pick up whatever flags you want (overwrite dirs or not, overwrite files or not) - check docs for details. You can also see there what are defaults.

If experimenting you can always run with --dry-run to check.

Only what you need to connect to your repo is its password. And obviously repo location - local path, S3 credentials or whatever you are using. Do not worry about local appdata.

1 Like

ok thats some good news
just because better safe than sorry, what about this?

I am using a s3-compatible storage (idrive), would i have to remember this string? I dont really know what is

edit: i guess is the username and maybe a random hostname to which kopia connects to the repo but can i change it? Is this linked to my data on repository somehow (?)

This is your local computer user and host name.

You do not have to remember it.

When you list snapshots it will show you from which host and user they were created.

Potentially if using your repo from another (new) computer you might have to adjust maintenance user - see details here. As only one user/host is allowed to run it.

1 Like

Your snapshots have info who created them as you can use one repo to backup from multiple sources.

I think GUI only shows you snapshots of user/host you are connecting with - you can change them when connecting though.

1 Like

oh ok now is more clear, i already did read docs about this (and the shared credentials among users etc) but still were somewhere confused, I am starting the server as --server-username=mich and not root is this ok anyways?

This is a container and the repository will only be used from that user in that container of that computer so i dont think i ll ever go across that

maintenance info shows that root@… correctly as a owner

IMO it is always better not to use root.

Though not sure what do you need server for… if you do not use it to backup multiple computers.

1 Like

There are many ways to skin a cat.

There is not one proper way:) Do it the way which suits you the best:)

1 Like

gotcha, thanks for your precious help

but i have a doubt, if is possible to backup data from more users, how can i retrieve the data if i dont have that root@477… string?
Kopia read that automatically from remote if locally is missing then

When you connect to your repo you can specify who you connect as (user/host). Default is your local machine user/host

but since this is a container the hostname is totally random, if i would re-create the container i would have a different string there

I am not using containers myself so won’t give you exact solution.

But user/host is the same sort of parameter like your S3 key/secret. Latter you have to provide and former either you let defaults (random in case of containers) to be used or specify explicitly.

Sorry since English is not my mother tongue (as obvious) I didn’t fully understood your message

That root@host is an actual key to repository? I mean without that I can’t access?

If yes then I could just change that to user@host for example (a random one that I can remember)

Ok better to use example:

kopia repository connect s3 \
        --bucket=... \
        --access-key=... \
        --secret-access-key=...

will connect using your container random user/host

but

kopia repository connect s3 \
        --bucket=... \
        --access-key=... \
        --secret-access-key=... \
        --override-hostname=my_server \
        --override-username=backup_user

will use backup_user/my_server

If you can pass --access-key to your container then you can also pass --override-hostname

Nope. Only what is needed to access your repo is its password. But the way kopia works is that you connect to repo using specific user/host pair - then e.g. in GUI your will only see snapshots with matching values.

Using CLI you can see all snapshots from your repo - but not by default - you need flag:

--[no-]all -a false Show all snapshots (not just current username/host)

Also you need specific user/host to run maintenance etc. When you run all on one computer it is not something you have to worry about but with your containers looks like you have to take it into account.

ok I did manage to figure this out, i deleted everything from my repository and started over again, i was using a quite badly made docker template

what matters is to use these flags when spinning up the container:

--hostname=kopia --cap-add=SYS_ADMIN -e PUID=1000 -e PGID=1000

if on unraid:

--hostname=kopia --cap-add=SYS_ADMIN -e PUID=99 -e PGID=100

and in both case should be mapped the device /dev/fuse:/dev/fuse for snapshot mounting (and sys_add permission, in alternative the container should be ran as privileged)

in this way I just assigned the hostname “kopia” to the container without any override from kopia itself, even if im still under root (root@kopia) but is ok for me

Now I know this use case may seem quite specific since you are quite losing or not considering the multi-user capability of kopia but I guess really many users have my same set up (only on unraid appstore both kopia images overtake the 1.5 million downloads)

For further (few) docs there is this repository: GitHub - imagegenius/docker-kopia where they made a really good job

Thank you again for your demystification !

Thx for sharing your findings! It for sure will be useful for people attempting similar setup.