Last year I was looking for an easy backup solution that works on windows, linux and mac.
I’ve heard some podcasts where @fd0 was talking about the principles of restic:
easy to use
git-like commands
easy to remember
…
They sound really nice and I agree to 99.9%
Today I wanted to test a new eclipse-version and because I’ve never did a “real-restore” with restic (until now only some small tests with mount, cat, restore) I thought this would be a good test.
Because the new eclipse-version did not worked as expected (and because I want to play around with restic) I’ve tried to restore my backup.
So the first try (without checking restic -hor the documentation) was restic restore 643bcf80
The assumption was that the folders where restored as in the backup (c:\Program FIles\eclipse to c:\Program Files\eclipse)
But the command told me I have to specify --target
So I’ve called restic restore 643bcf80 --target .
Now restic restored the absolute paths in the current directory. C:\restic\c\Program Files\eclipse in my case.
At least until my disk run out of space.
So I wanted to filter the contents (because the backup contained also my workspace).
I had to do some tests and googling until I’ve found out that I have to use --include c\Program Files\eclipse (without : in the path) to restore a specific folder.
With enough space and the right commands I was able to restore my backup.
I really like restic up to now but in my opinion the restore command does not really match the principles mentioned above (or at least my expectations).
I would really wish some kind of cp command (with cp-syntax) where I can copy files and folders from a snapshot to a defined location on my disc (so I don’t have to move the directories to their place after restore).
E.g. restic cp 643bcf80 "c:\Program Files\eclipse" "c:\Program Files"
or in docker-style restic cp "643bcf80:c:\Program Files\eclipse" "c:\Program Files"
→ I don’t care if I have to use c:\ or c\
Unfortunately my wishes on github got rejected
So I just want to ask if I’m the only one who thinks that the restore command is not that intuitive than it could be.
I’d vote for a syntax like restic restore "643bcf80:c\Program Files\eclipse" "c:\Program Files", see also A restic client written in rust - #28 by alexweiss to make some advertisement (Windows support for rustic is however not tested and most likely not yet fully working…)
The syntax of restore is fine for me. But I must say that now after all these years I am used to it.
What I really miss is a progress bar or some other progress indicator
Thanks for your comment and hint to rustic.
I know that are reimplementations of restic but at least for now I want to use the orignal one.
even though that (in my opinion) a lot of wishes where rejected or there is no time to implement.
→ no offense - I know it’s an open-source project, it’s free and is done in the spare time of the developers.
@alexweiss Please once and for all stop your continued advertising of rustic. This forum, GitHub and the other restic community places are meant for technical and user discussions about restic - they are not meant to be an advertising platform for rustic (or any other backup software for that matter).
If you want to discuss rustic in this forum, please do so in the rustic thread in the community category, which is where community contributions are meant to be discussed. Other threads and discussions, wherever they are, should be on topic and focused on restic.
Looks interesting but restic snapshots shows always the full paths and this would also mean to do some more work to backup multiple paths with the wanted relative folders.
→ currently I’m collecting all relevant paths in an include and exclude file to keep it simple.
Correct, it shows the drive prefix as well, but this is misleading. You can see the actual path stored in the snapshot with restic ls instead. When you use the method above, restic ls will print a path without the drive prefix /c/. That also means that you can directly restore to the original location without moving files.
this would also mean to do some more work to backup multiple paths
I don’t see why there would be more work? You have to switch to the root of the drive first and use a slightly different path (without the drive prefix), sure. But everything should be the same effort. And you get the ability to restore directly to source without moving files.
Here is a simple example (“backing up the Desktop without the folder donobackup”)
Just to clarify, I am not opposing your request (or other similar requests). I would welcome a feature that adds more flexibility when restoring files/folders (even only something basic like the tar parameter --strip-components).
Dear @rawtaz
You might be right that by linking to rustic I do some advertisement and if this offends you or anyone else, I would like to excuse for that.
So, we are here in a technical and user discussion where I or others propose or ask that restic may behave differently or may have additional features. I do have a hard time trying to imagine that referring to other software which does have this feature is that much off-topic. Especially if the other software is able to fully process a restic repository.
You might want to prevent such a change or feature in restic and as a restic maintainer you are perfectly fine to do so. In my opinion, however, you should be able to withstand that others are willing to implement such a feature and may even have proofed it is possible.
And here is a side remark: Open source is very much about community. And community gets stronger if people have fun and get positive feelings about what they are doing. If you have ever asked yourself why for instance a strong contributor to restic stopped working on PRs, one reason could be a decrease in that fun and positive feelings. Now, for me it feels that this discussion has turned into a strange direction. Maybe this was your intention, maybe not. I have to say, first I thought about just forgetting about it and go improve some software. However, I think you deserve getting this feedback.
@alexweiss I’m well aware that unfortunately too many of your PRs are sitting there since a very long time and haven’t gotten any feedback so far. So why is that? It is not because we aren’t interested, but rather because they’re adding tons of substantial features and therefore require a lot of work to discuss and review. Especially, questions like “do we want this feature?” or “what is a good interface for it?” take a long time to answer. Even more so as we want to keep the CLI interface stable and lean if possible. And of course, there are also other forum posts, issues and PRs that want attention (a few dozen every week), and then I also want to code some PRs of my own. We’re still in the process of digging through the pile of PRs that have accumulated (we’re down to about 50 starting from 100 open PRs) and it’s progressing slower than I’d like.
Is that what you’re referring too? What could we do better? We can also move this to a different thread or a private conversation if you like.
this thread was ment to be as discussion what could be improved - even if I was talking about the restore-process in particular I’m totally fine if we extend the topic.
Even if I think that you’re all doing a very good job I would whish that you would be more open minded in regard to “do we want this feature”.
e.g. I’ve seen “you can do this with a script” as answer in some discussions.
Thats right of course but also forces the users to build their own scripts or they have to use scripts from other authors.
and if you want to use restic on windows, linux and mac you’ll rely on different scrips from different authors with different features.
or if someone can write his own scripts he still have to do this for each os.
imho it would be nicer to have more features in restic to not rely on additinal authors.
I know that more feature will extend the codebase but it would also extend the usability.
stable cli sounds good but this should not prevent the improvement of usability.
→ maybe you can just set old commands deprecated if there is a newer and better one so all have a chance to adapt theire workflows.
“Unfortunately” the day has only 24 hours and I would assume that you also have a real live besides restic.
But I would really wish that you have more time for restic.
this is just my subjective opinion after reading some discussions on github and in the forum.
Nevertheless I still like restic - thank you for that great piece of software.
Actually this is part of the story. It is kind of frustrating when wanted or needed features don’t become available for a long time. Even more when you try to support and realize that this doesn’t speed up things much.
Another part is the tone of the conversation. I have encountered many very respectful discussions within restic and saw this project as good examples. But I also encountered irritating things. Maybe this is inevitable once a project gets a bigger size and more people being involved. But still - I’m not at work where I get paid for enduring difficult situations. I’m doing all in sparse time and when I don’t have fun, I stop doing such things.
That said, I don’t want to blame anyone here - you are all also doing this voluntary in your free time and I have big respect for this and for you!
About the open PRs: I am happy that I already implemented all features which I personally missed in rustic. I actually don’t feel that much like working in Go anymore - I’m much more efficient when programming in Rust and as a consequence, I am happier when programming in Rust . So, feel free to do what you want with the PRs. I was thinking about closing them, but if you think there is anything worthwhile, use them or adapt them to your needs.
I like that there is a --target with restic restore, because I would fear (without reading the documentation) that it overwrites any changes on disk and I almost never want to lose data / go back for all files and folders. That’s why I am happy to restore files to a --target and then manually copy what I need. Or even mount a snapshot and copy what I need.
And if I really want to got back to a restic snapshots for all files, I could use the target /, can’t I?
But unfortunately mount is not support on windows yet.
And if I really want to got back to a restic snapshots for all files, I could use the target /, can’t I?
I don’t think so.
On windows the : is removed from the paths.
Afaik if I would restore C:\Users from a snapshot it would only add the backuped files to the existing folder instead of restoring the original state (which would remove additional files in the target dir)
I see. I have no solution for an inplace restore, then, other than deleting everything, restore to some directory and move the restored directories in place by hand. I never had the need for that (and depending on the backuped folders, it might be dangerous on a live system) but it looks like a valid scenario to me.
I also don’t have the need (yet) but this was what I’ve expected by executing “restore”.
My use-case was just to copy some files from a snapshot and in my opinion it was not that intuitive and I wished some cp-like command because I would assume everybody knows how it worked.
(Windows support for rustic is however not tested and most likely not yet fully working…)
