The following is a rough roadmap draft for upcoming restic versions. The roadmap for restic
0.18 and 0.19 only contains the planned major features, we’ll see about the rest once we’re there.
The plan may change over time depending on newly arising issues or pull requests.
The “reduce number of … PR”
task is a wildcard task to slowly reduce the number of waiting PRs without completely
stopping the development of new features.
Not knowing that restic 0.16.3 (great program, btw!) doesn’t do ‘inplace’ restore, I just did that a week ago. And for what I experienced, it worked. So, what am I missing? What did really happen when I restored /opt/local with restore -t / (as root)? It seems to have just worked.
There are some corner cases like readonly folders that cause problems; overwriting symlinks was only fixed a few releases ago. The main improvement for inplace restores will however be the support for resuming restores.
The roadmap for restic 0.18 is now tracked at Restic 0.18 roadmap · GitHub . Given that the development for restic 0.17.0 took so long, we might end up splitting restic 0.18.0 into two smaller releases.
Could you please explain a bit why it is a BIG weakness?
--sparse flag will indeed as per docs:
Note that the exact location of the holes can differ from those in the original file, as their location is determined while restoring and is not stored explicitly.
does not restore exact sparse “format” but I am very curious what real life problem it causes? As if it is important than maybe it makes sense to prioritize it above some other issue. Or it is mostly “cosmetic”…
During the backup, Restic does not store information about the “sparseness of a file” (such as how many “holes” it has). As a result, Restic is not able to restore sparse files to their original state. In fact, by default, Restic will restore sparse files as “normal” files (with inflated “on disk” sizes). The --sparse option applies to all files (even files that were not sparse before). If you run a restore with that option, all files could be restored as sparse files (which is bad).
Most users who have restored a backup with sparse files probably have experienced the “size surprise” … (or maybe even the “out of disk” surprise?).
PS
Duplicacy (also a deduplication backup tool) handles sparse files correctly.
Yes it would be nice if restic can preserve as much info and structure about files as possible including “sparseness of a file”,
but at least myself I do not see it as critical or very important. Unlike for example extended attributes preservation. Because latter leads to information loss.
I think I have few programs using sparse files - after restoring from restic backup they will work perfectly fine regardless if I remember about --sparse flag or not. As for the unexpected files becoming sparse - it is almost benefit:) saving me some disk space. Overall I do not think that it matters much for my (maybe minority) case.
Of course I can imagine some cases where people use some software which creates many large (exceeding real free disk space) sparse files. This is exactly where --sparse flag becomes handy.
Maybe it should be default for safety? But this is different story.
Overall I am saying that it is “would be nice to have” restic feature but by no means it is “must have”. So should be prioritised accordingly:)
The Restic developers will never make this option default, because having too many sparse files in a filesystem is bad for performance.
So should be prioritised accordingly
All I asked is to put it on the roadmap. I did not demand “it has to be in 0.17.5” asap Just put in on the 0.19 milestone (which will probably be completed two to three years from now, based on the release history). Or on 0.20 …
In the meantime, I will be using Duplicacy for folders that contain sparse files.
I’m currently rather hesitant to add anything further to the roadmap for now. There’s already enough queued for 0.18 to probably require two releases and 0.19 also has the chance to spiral out of control.
Planning any further would require taking a look what other feature have also been asked for. But it’s too early to do that now.
Just put in on the 0.19 milestone (which will probably be completed two to three years from now, based on the release history). Or on 0.20 …