Add Description to Existing Snapshot

[ossie-git]

Hi,

From what I can tell, the --description option is only available when creating a new snapshot. As I would prefer to use resticprofile for taking the actual snapshot, is there any way to add a description to an existing snapshot? Thanks

[aawsome]

You are right - a possibility to change the description is currently missing.
Similar with the label - but here there is the possibility (using the nightly builds) to change it via the interactive mode rustic snapshots -i.
I'll add a possibility to change descriptions, too (maybe starting with the interactive mode)

[aawsome]

@ossie-git Changing snapshot descriptions using rustic snapshots -i will be available tomorrow in the nightly builds and also in the next release.

Just out of curiosity: What are your reasons to not use rustic to do the actual backups?

[aawsome]

Ah, and of course: Feedback to rustic snapshots -i is also highly welcome!

[ossie-git]

@ossie-git Changing snapshot descriptions using rustic snapshots -i will be available tomorrow in the nightly builds and also in the next release.

Thanks a lot

Just out of curiosity: What are your reasons to not use rustic to do the actual backups?

I'm a little new to Restic and currently use resticprofile. From what I can tell, Rustic doesn't currently have its features (unless I'm mistaken)

[aawsome]

I'm a little new to Restic and currently use resticprofile. From what I can tell, Rustic doesn't currently have its features (unless I'm mistaken)

Yes, for sure there are features in resticprofile/restic which rustic misses (as there are unique features in rustic). I was curious about which specific feature(s) you are missing in rustic.

There is of course nothing wrong with using your setup, I was only wondering how we can improve rustic to make it suite more users' needs.

[ossie-git]

Thanks. Like I mentioned, I'm still new to Restic and after looking at this comparison, I may end up using Rustic. However, a few things that make me less sure are:

• the lack of thorough unit testing which is a must when it comes to backups IMHO
• the lack of support for something like resticprofile (I wonder if resticprofile can be used to call rustic under the hood instead of restic)

[aawsome]

@ossie-git Thanks for your feedback!

• the lack of thorough unit testing which is a must when it comes to backups IMHO

Fair enough. We are working on this and unit tests for backup are already in place. Besides unit tests, feedback from a solid user base is IMO even more valuable, that's why I am hoping that more and more people trust into rustic.

Just one note about the description: This is so far a rustic-only feature. Which means that you still can use your snapshots and repository with restic, but restic won't show you the description you added with rustic (unless they also implement that feature).

• the lack of support for something like resticprofile (I wonder if resticprofile can be used to call rustic under the hood instead of restic)

Sorry, I didn't fully get this point but I think this is because you are new to restic / rustic.

First, resticprofile is not much more than a tool which basically calls restic for all operations it's doing. I call it a wrapper-tool. It uses the restic binary and calls it and processes the restic json output. With rustic, of course any tool can do the same as rustic also supports json output (and every CLI tool can be also called by any other software). But in contrast to restic, rustic_core is available as library. So, additional to the possibility to call rustic as binary, a software author can call rustic_core and compile it into its binary. This has the advantage that the dependency on a foreign binary is removed (and also it might be faster and more powerfil than calling another executable).

Second, yes, there are not many tools like resticprofile available for rustic. The existence of such tools is mainly coming from the fact that supporting configuration files has been excluded from restic's scope for a long time, see restic/restic#16.
rustic on the other side has built-in support for config profiles. And we are open to supporting all needed features to run rustic directly instead of needing wrapper-tools to get needed functionality for your every-day work. That's why I was asking if you are missing something.

Anyway, if at any point you come to the conclusion that some feature is missing for you in rustic, please don't hesitate to open an issue. And, if you want to use a restic/rustic setup and are satisfied with this, of course use your setup!

[ossie-git]

Thanks. Will have a look at config profiles. Like you said, I'm still new to Restic and Rustic. By the way, the snapshot description feature works. Thanks a lot

[simonsan]

• the lack of thorough unit testing which is a must when it comes to backups IMHO

Fair enough. We are working on this and unit tests for backup are already in place. Besides unit tests, feedback from a solid user base is IMO even more valuable, that's why I am hoping that more and more people trust into rustic.

I think trust into rustic's abilities/reliability and testing are correlated here. It's harder to build trust for things that aren't thoroughly tested.

So from that POV, a solid user base is depending also on the foundations, which includes testing.

It's a bit like a hen-egg-problem. Even if the user base would be solid already, there still need to be more tests making sure the bugs the users find are being taken care of long-term and no regressions are introduced further down the line. In that regard, each bug being fixed could include a test proving that it has been fixed, and so on.

So while I agree that a solid user base is valuable, also for finding and reporting bugs. For a backup tool, it's not as easy to build up that solid user base if it would heavily rely on the user base itself to report bugs. Because I assume the software's goal itself (e.g. data protection) attracts people that are more critical towards these things. So it is less likely that the people give a leap of faith in that regard. Which is understandable.

Important

IMHO it's on us, as rustic maintainers to prove to restic users that rustic is working as reliable as restic and that it's usable as a replacement in most cases. We shouldn't be thinking about a leap of faith, but rather implement a test and benchmarking suite comparing rustic and restic to let users make informed decisions.

One starting point to prove that (e.g. within our testing suite), would be to show that you can back up and restore with restic and rustic alike. So that rustic at least works as reliable as restic.

So something along the lines:

• dir/file fixtures
• backup with restic/restore with rustic -> restored files bit-identical to the original fixtures
• backup with rustic/restore with restic -> restored files bit-identical to the original fixtures
• backup with rustic/restore with rustic =(restored files bit-identical)= backup with restic/restore with restic

Which would show that rustic/restic can be used interchangeably for this use case. And then we could do that for other use cases as well.