It seems like Resitc process progress stops with B2.
ETA numbers do update, and the elapsed time is running, but no other progress and hardly any CPU usage, and no file network traffic for 24 hours.
I am running Restic in a container in a Synology device using GitHub - djmaze/resticker: Run automatic restic backups via a Docker container. so observing the docker with “docker stats” shows me that no outgoing traffic.
It’s been running 14 days now (huge over 100TB repo, and over 2M files). I have done 3 earlier snapshots on this data (locally once and once remotely).
Unsure what to do now. Restart would feel like a huge waste of time. Anything I could do to investigate?
Most importantly, could process be doing something still and continue?
Actually, it was not hung inifinitely, and the process continued next day I checked. No idea what happened.
If you add a large amount of data within one run of restic backup
, this experimental PR may be interesting for you:
restic:master
← aawsome:backup-resume
opened 01:10PM - 16 Jan 21 UTC
What does this PR change? What problem does it solve?
-------------------------… ----------------------------
This is a follow-up of #3229.
In this PR I made a PoC using the idea of user odin from the forum, see link below.
With this PR, restic writes a temporary file (in the cache dir to the selected repo, subdir /resume/) which contains the list of already finished directories and the tree ID where it is saved in the repo.
If the backup suceeds, the file is removed.
At the start of a backup, restic tries to read the temporary file (if existing) and uses the contained trees as "additional parent trees" for the given directories. This means that w.r.t. already saved trees, this resumed backup is as fast as a follow-up backup using a parent snapshot.
Note that this PR relies on #3121 which should be merged first.
Was the change discussed in an issue or in the forum before?
------------------------------------------------------------
closes #2280
alternative to #2960
https://forum.restic.net/t/quicker-interrupted-backup-resumption/3470/6
Checklist
---------
- [x] I have read the [Contribution Guidelines](https://github.com/restic/restic/blob/master/CONTRIBUTING.md#providing-patches)
- [x] I have enabled [maintainer edits for this PR](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
- [ ] I have added tests for all changes in this PR
- I have not added documentation for the changes (in the manual) - there is also none for parent snapshots
- [x] There's a new file in `changelog/unreleased/` that describes the changes for our users (template [here](https://github.com/restic/restic/blob/master/changelog/TEMPLATE))
- [x] I have run `gofmt` on the code in all commits
- [x] All commit messages are formatted in the same style as [the other commits in the repo](https://github.com/restic/restic/blob/master/CONTRIBUTING.md#git-commits)
- [x] I'm done, this Pull Request is ready for review
1 Like
Very nice PR. I wish I had known about this earlier Thanks for the note.
I am running my restic in a packetized docker container (resticker) in a synology device that is loading the docker images from a registry. I am not sure how to get the custom build PR build to such a container.
My backup has now been running for 19 days. It says 80% done, but I think most of the new files are in the remaining portion, so it might still be running the same amount.
I just hope for no electricity cuts now If I find a way to put the PR-build to the docker runnable in Synology I will give it a go.
Just out of curiosity, did this PR or something like it end up in the 0.13.1 release?
I saw the changelog mentioning something like this.
dhopfm
June 14, 2022, 1:02pm
6
No, this particular PR hasn’t been merged yet. It’s not part of v0.13.1 and yet needs to be merged in order to make it into a future release.