Does it make sense to backup "index", "snapshots", "keys" folders?

From documentation Troubleshooting — restic 0.17.3 documentation
it advises backing up those folders in case of troubleshooting but what about regular basis?

Does it make practical sense to have those folders be backed up? If yes how it should be after every new snapshot created?

1 Like

Indexes, no, they can be recreated by restic repair index.

Snapshots, maybe, because they are what makes up your “points in time” for the backups - they are not your actual data, but you need them to be able to restore a consistent set of files from the points in time that you backed up your data. But if this is a concern, the question becomes, why would your snapshots files be lost and not at the same time the other files? It’s more relevant to ponder the risks of corruption on disk, and if that happens it’s usually something that affects a few snapshots, not all of them.

Keys, yes, as they cannot be replaced without at least one key working to access the repository.

The config file, yes, as it contains information used by restic to process the repository correctly and even if you can work around a missing config file, it’s clearly something you would prefer not having to do :slight_smile:

I hope I got all of that right. Someone please correct me if I wrote something that is wrong.

5 Likes

thanks for so detailed answer.

Config file and Keys folder are pretty stable and don’t change over time, doesn’t it? Meaning one time backup is okay until I change password or specific configuration.

Snapshot looks like should be backed up after each snapshot created, Restic itself doesn’t allow to access it? Have to use native API in case of s3?

Config almost never changes, one example of the few times it does change is when you use the restic migrate command. For example upgrading the repository version from v1 to v2 requires rewriting parts of the config. But generally speaking it is more or less never changed.

Snapshots, I honestly don’t see why you’d be more inclined to back those up than the other files in the repository. I certainly don’t see any point in backing up your snapshots files after every backup, that seems like solving the wrong problem somehow. Better look into having multiple repositories instead, in different places.

You do understand that it is not the snapshots files that actually contain the backed up data, right? Backing up your snapshots files will not enable you to restore your data. The are equally or arguably less needed than other files in the repository.

1 Like

Yes.

Just to double check.

@rawtaz
Why do dumb users ask stupid questions :wink:
Because from ordinary user perspective if I have 2 files to backup file1 and file2, restic will divide them in hundreds parts and again from ordinary user perspective snapshot file is a magic file with instruction how to restore back those hundreds parts into file1 and file2

and as far as snapshots files are small it’s not a big problem to store it, besides the case they are changing frequently.

I got your point in previous message, just try to explain the logic :wink:

I never thought you asked stupid questions, sorry if that’s how it came across. I just wanted to make sure you understood what snapshots are since I guess that part can be misunderstood (as in the user thinking it’s the snaphots that hold the data, and thinking that in order to back up their repository the snapshot files is what to back up).

Snapshot files actually never change, they sit there until you forget them or rewrite the snapshot somehow.

1 Like

it’s not yet all my questions haha :grinning: :grinning: :grinning:

I’ve downloaded keys and config, while
keys is a plain text file with salt and data inside
config is binary file and I am not able to open it with text editor

Is it correct?

Yep, that is as it should be :slight_smile:

1 Like

oh yes I forgot, is it key file a secret, if it’s stored on the repo which can be considered as not private.

I mean can I backup it as it as, or should I backup it privately?

Restic’s entire design is based on the assumption that the storage cannot be trusted. But it still puts its key files there. Yes, you can rest assured that the key files are fine to store in a non-private place.

Keeping the backups private usually doesn’t hurt as this provides an additional line of defense against attackers (one can’t try to brute force passwords without access to the key files). But as long as you use a reasonably secure password, there’s not much an attacker can do.

2 Likes

The only folder that takes up significant space is the data folder. I just backup the whole repository, I can’t see why there’s any need to exclude particular files or folders, other than the key if your backup storage is not secure.

2 Likes

It makes a bit of sense to include snapshots, if you have frequent automatic backup. Snapshots are tiny compared to everything, and its would probably be annoying if a disk error caused loss of most snapshots, because then restore would become a pain, or so I assume.

I prefer also to have a separate manual backup, in case the automatic backup script fails miserably and deletes files.