Dealer Style Restic

The project

The same repositories, in less time.

restic backs up files into encrypted, deduplicated repositories. Dealer Style Restic is a build of restic 0.19.1-dev (upstream commit ba802d42b7294c98b62c16d1157ea3e80820c019) that does the same work in less time and with less memory. It keeps the commands, the options and upstream's defaults.

It keeps the repository format. Chunking and blob IDs are identical, and data and tree blobs are stored in the same form upstream stores them, so each program reads what the other wrote and deduplicates against it. Index and lock files decode to the same content but are encoded slightly differently: they are valid Zstandard, and upstream reads them.

Everything the program uses has been authenticated and hash-checked when it was read. In two places this build keeps what it read where upstream reads again: restore's second pass reuses directory trees that its first pass verified and kept, and an index read during the lock wait is kept if a listing taken after the lock is confirmed still shows the same names and sizes. Both are described under known limits.

It came out of a measured search. Teams of AI agents proposed changes to restic over 20 seasons. A fixed judge timed every candidate against upstream and compared its results with upstream's before any time counted. Independent reviewer agents then read the code for soundness. They found one defect that could silently break a backup and 10 more findings, and all of them were repaired. Release checks found 4 more failures, which were fixed. Then 3 reviewers of a different model family, given only upstream's source and the tree, found no data loss and reported further findings: 9 were fixed and 2 are documented differences. What is published is the speed that was left afterwards.

What it is not

It is an experimental, independent derivative. It is not affiliated with or endorsed by the restic project. restic is the work of its authors and contributors; Slop Dealer's contribution is the published optimisation work, the measurements and the reviews. Report problems with this build to the Dealer Style Restic repository, never to upstream. Some error messages inherited from upstream still link to upstream's issue tracker; for this build always use https://github.com/slopdealer/Dealer-Style-Restic/issues.

Try it on a separate test repository first. Back up a copy of real data with this build, run upstream restic's check --read-data on the result, restore it and compare the files. Only then point it at a repository you care about.

Measured performance

Read the comparison.

Every timing below comes from one Linux machine (AMD EPYC 9454, 48 cores, 128 GB RAM, Linux), with 4 pinned CPUs for each judge job, the CPUs held at full clock (the performance frequency governor), and the corpus, repositories and restore targets on memory-backed storage. Each comparison is paired: in every round, every command is run by upstream restic and by this build back to back, on fresh copies of the same repository state, and the order rotates. A result counts only if the build's output matched upstream's.

The judge measured working commit b8cf439. The published source is commit 8f9372b, which changes one comment and adds one test and builds to the same machine code. The exact statement is with the downloads, and the full account is in section 2 of the repository's RESULTS.

Against upstream restic

The published tree was ahead of upstream in 44 of 44 paired rounds. By workload the time saved runs from 17.26% to 45.13%. The workloads are described under methods. In short: main is many small files; big-index is the same with 1,500,000 extra blobs in the repository's index; large-files is a few very large files; remote is main's files with the repository behind a simulated network link.

More than 4 CPUs

The published machine code was then run at 8 and 16 cores. All 56 cells, seven commands on four workloads at two core counts, are ahead of upstream; the smallest is remote check-read-data at 16 cores, +5.51%. In restore, forget-prune and ls this build uses more user CPU than upstream, and the gap widens with the number of cores.

Many directories. One result changes sign with the conditions. For a restore that is almost only directories, on a machine with many CPUs under a load-following frequency governor (the usual setting), this build was 4.8 to 10.7% slower than upstream in 4 readings. On 4 cores under the same governor it was 26.8% faster, and with the CPUs held at full clock it was 16 to 18% faster. The measurements, upstream against this build, on the release-check CPUs: 606,060 directories and 3 files, three rotated rounds. Load-following governor, with the official judge job running beside it: 16 CPUs 67.2 s against 74.0 s (10.1% slower); 4 cores 86.5 s against 63.3 s (26.8% faster). The same CPUs held at full clock: 16 CPUs 53.3 s against 44.7 s (16.1% faster); 4 cores 53.5 s against 44.1 s (17.6% faster). Load-following governor again, on a quiet machine: 16 CPUs 68.0 s against 75.3 s (10.7% slower). Larger snapshots under the load-following governor with 16 CPUs: 1,010,100 directories, 7.8% slower (three rounds); 2,020,200 directories, 4.8% slower (one run per build). What this settles: holding the CPUs at full clock removes the loss, and a quiet machine does not. The cache layout was ruled out before: at full clock, on eight cores spread over four cache domains, the same restore was 16 to 17% faster than upstream. So the judge job that ran beside the first measurement did not cause the loss. In the quiet run the mean clock of the running CPUs was 2.55 GHz for upstream and 2.02 GHz for this build, and the CPU seconds were 71.4 against 98.7; at the fixed clock both used about 55. That this build spreads the work over more threads, so that the governor sees less load per CPU and keeps the clock low, is an inference from the clock readings and the CPU seconds, not a measurement.

By command

Each workload runs the same seven commands. The grid shows the time saved against upstream for each command on each workload.

Across the 28 cells the time saved runs from 5.55% to 70.75%, and in 28 of them the build was ahead of upstream in every round. The first backup saves 6.83% to 17.33%, depending on the workload: most of its time is reading, chunking, compressing and encrypting the data, which this build does as upstream does.

Season by season

The league ran 20 seasons, from 24 September 2026 to 7 October 2026. 17 of them ended with a new tree and 3 did not. The way the league scored changed three times, so the chart follows the one measure that was recorded throughout: time saved against upstream on the main workload.

Against the league's last champion: what the repairs cost

The league's last champion, the tree it promoted in season 20, was faster than the published tree. The champion also carried the lock-wait defect at three new places, and it stored some blobs in a form upstream does not. The published tree was measured against it directly, in the same job as the comparison with upstream.

By the league's own promotion rules this tree would not have replaced the champion. It was ahead of the champion in 6 of 44 rounds, where promotion needs 29. Its time over the four workloads was 1.06% worse, where promotion needs a gain of at least 0.25%. Its peak memory was 8.65% higher, where the guard allows 2% (by workload: main 12.62%, big-index 5.17%, large-files 7.23%, remote 9.58%). Two workloads were more than 1% slower than the champion: large-files −1.07%, remote −2.18%. The difference is the price of the correctness repairs and of the fixes from the independent review.

The tree as it stood before the independent review's fixes read −0.79% against the champion in its own job of 44 rounds (ahead in 6). Those are two separate jobs, so the difference between them is an indication of what the fixes cost, not a measurement.

The repairs alone, in their final form, cost 1.98% of the time of a pass against the tree they repaired (bench, 4 CPUs: main −2.00%, big-index −1.72%, large-files −2.55%, remote −1.66%) and added 39.2 to 84.8 MiB to the sum of the seven commands' peaks. As first staged, before two avoidable costs were found and removed, an official job of 12 rounds read −3.15% (ahead in 0 of 12). Returning to the form in which upstream stores blobs that do not compress cost 0.70 to 0.79 suite points of that on its own. The final merge also brought in sound work the league had not promoted, which is why the published tree ends closer to the champion than the price of the repairs alone.

A workload the teams never saw

One workload was held out for the whole league, to test whether gains fitted to the visible workloads carry over. The teams could not select it. Like the main workload, it is dominated by many small files. It was measured at season boundaries only, each tree against upstream, 12 paired rounds on 4 CPUs.

From season 11 on, the gain on the held-out workload is within about one point of the gain on the main workload, and the steps from season to season reproduce. The early seasons, which were also scored on memory, carried over about half of their main-workload time gain. A full pass of the held-out workload took upstream 46.67 s and the tree after season 19 32.35 s. The large-files and remote workloads have no held-out counterpart. The published tree itself has not been run on the held-out workload.

rustic, Kopia and Borg, as measured

On 3 October 2026 the league tree after season 15 was run beside three other backup programs on the main workload's corpus: the same seven steps with each tool's nearest equivalent command, encryption on and zstd-class compression everywhere, 4 CPUs, 10 repetitions. This is one measurement of an earlier tree on one workload. It is not a benchmark of the published tree, and the other tools were run at their defaults by a team that knows restic better than it knows them.

• Kopia was the fastest overall, at 14.48 s against 17.07 s for the league tree. The lead is in repeat backups: 0.52 s against 1.51 s when nothing had changed. It used about four times the memory. Its restore differed from the source in 10 of 10 runs: a file name that is not valid UTF-8 was stored altered, a named pipe was skipped without an error, and hard-linked files were restored as separate files.
• rustic read 23.51 s as run. The method used to hold the CPU clocks steady penalised its worker pipeline; without that the estimate is 19.2 to 20.2 s. It used about four times the memory of the league tree, and 5 of its 30 runs had a command fail on an error in its local cache. The repositories themselves were intact.
• Borg took 49.10 to 54.54 s. It works on one core. Its memory use was close to restic's.

What did not work

• Three seasons promoted nothing. Seasons 2, 3 and 7 ended without a new tree. In each, the nominee's 6-round screen (+1.29%, +1.47%, +2.08%) shrank or reversed at 42 rounds (−0.53%, +0.49%, +0.014%).
• Searching without a map. Seasons 1 to 3 searched unaimed and circled one corner of the backup path. Two later seasons with open scope and no new map added +1.11% and nothing.
• Scoring memory and time together. By season 12 the equal-weight score was paying for memory with time: 14 of that season's 16 match rows were slower than their incumbent. The promoted tree was 0.64% slower than the one before it.
• Scoring one workload. On two new workloads the tree after season 15 held about half of its main-workload gain, and its check --read-data on a large index was 33% slower than upstream. On the first simulated link, the tree after season 17 was 3.25% faster than upstream, against 27.61% locally.
• The automatic season merge. It ran in four seasons and merged nothing in any of them: the best trees per phase edited the same files. Unpromoted work reached the tree only through three hand merges.
• Work inside the lock wait, as built in the last season. It led the menu with an estimated bound of +4.9 points and all four teams built it. The three mechanisms that were promoted cost 0.14 suite points together when measured against the same tree without them. The review found them unsound. None is in the published tree.
• Storing incompressible blobs raw. It saved time on the first backup, and it made prune --repack-uncompressed rewrite the same 16,179 blobs on every run. The published tree stores every blob in upstream's form, at a price of 0.70 to 0.79 suite points.
• Guessing compressibility from a sample. The sampler stored a redundant blob at 1,048,608 bytes where upstream stores 65,661. It was removed.
• Setting a file's metadata as soon as its last blob is written. Two teams tried it in season 20. An executed test showed that it changes what a later fatal error leaves behind. Both teams kept upstream's order.

How it was measured

The league, the judge and the noise.

The league

The search was run as a league. From season 2 there were 4 teams, T1 to T4. A team was a set of AI agents with fixed roles: an owner who chose where the team searched, a coach who planned each match, builders who wrote and measured the code, and inventors who proposed ideas. A coordinator agent ran the seasons for one human operator, who set the rules and made the rulings.

A season had 4 matches. In a match each team handed in one source tree. The judge built it, checked it and timed it against the incumbent (the best tree so far) and against upstream over 6 paired rounds, 8 from season 19. That is a screen: enough to rank trees, not enough to believe a number. From season 13 the 3 best screens were measured again at 12 rounds, the rescreen, and the best of those went to one long confirmation of 42 rounds, 44 from season 19. A tree became the new incumbent only if its confirmation passed every gate:

• ahead of the incumbent in at least 29 of 42 rounds, with a median gain of at least 0.25%;
• peak memory no more than 2% above the incumbent's, on every workload;
• no workload more than 1% slower than the incumbent;
• faster than upstream;
• and all of it only after every correctness check had passed.

The teams worked under fixed rules. Only non-test Go source under cmd/ and internal/ could change, with no new dependencies. The repository format, the output, the exit codes and every integrity check had to stay as upstream's. Detecting the benchmark was forbidden. The 200 ms lock wait could be overlapped with other work but never removed or shortened. No code could burn CPU to influence the clock.

The teams ran on these models, as the season reviews record: season 1, a single team on a provider's unnamed preview model; seasons 2 to 11 and 13 to 15, GPT-6 Luna at maximum effort; season 12, GPT-6.1 Sol at high effort; season 16, Luna and then Sol at medium effort from mid-season; seasons 17 to 20, GPT-6.1 Sol at medium effort. The reviews, the repairs, the merges and the release checks were done by other agents.

The judge

Three arms on one bench. A judge job measures three builds: the candidate, the incumbent and upstream (the judge's files call it stock). The judge builds all three itself, offline, from source with one pinned toolchain (go1.27.0). Upstream's build must come out bit-identical every time.

Paired rounds, rotated order. In a round, each of the seven commands is run by all three arms back to back, each on a fresh copy of the same repository state, which upstream prepared. The order of the arms rotates through 6 patterns. Positions balance exactly over complete cycles; in the final job of 44 rounds this build ran first, second and third 12, 16 and 16 times. The value of a round is the paired difference within it. Reported figures are medians over the rounds, the number of rounds in which the candidate was ahead, and a 90% bootstrap interval (4,000 resamples).

Seven commands. A first backup; a backup with nothing changed; a backup after a set of changes; a full restore; check --read-data; forget --prune; and ls --json. Each is one restic process with upstream's defaults, in a sandbox with no network, on 4 pinned CPUs, with an empty local cache. Time is wall-clock time around the process. Memory is the process's peak resident size as the kernel reports it at exit; no garbage-collector tuning is set.

Correctness, every round. Before any timing, each arm runs every command once and upstream checks the result. Upstream runs check --read-data on the arm's repository, restores it, and compares the restored tree with the expected one entry by entry (content, modes, owners, times, symlinks, hard links, extended attributes, odd file names). The arm must also detect a deliberately corrupted pack. Then, in every measured round, the arm's snapshot records must equal upstream's. Equal root tree IDs are the fast path; if they differ, upstream must fully check and restore the result, and its manifest must match. The arm's restore must equal upstream's restore. After prune the kept snapshots must be upstream's and upstream's check must pass: the warm-up reads all the data, and the measured rounds rotate through fifths of it. The arm's JSON listing must parse equal. One failure aborts the job. Upstream's own test files for the storage packages and its command-line integration suite are also compiled against the arm's code, and must pass wherever upstream passes (1,026 tests). In the job behind the tables above, 1,019 of 1,019 such units were verified.

Four workloads, and why each exists

main

91,264 entries, 1.64 GiB: 90,000 small files in a project-like tree, medium and large files, exact duplicates, a sparse file, and a block of awkward entries (odd names, links, special modes, a named pipe). The changed version applies 4,224 edits. It was the only workload until season 16.

big-index

The main workload, with 1,500,000 extra small blobs already in the repository, so every command that opens the index carries them. It exists because the gains had been fitted to main: the tree after season 15 saved 21.16% on main and 11.81% here, and its check on this workload was 33% slower than upstream's.

large-files

3,217 entries, 2.91 GB: a sparse disk image, a page-structured database file, logs, incompressible media files and a small tree. It exists for the same reason: the tree after season 15 saved 13.00% on it.

remote

The main workload's files, with the repository reached through restic's REST backend over a simulated link. It was added to the score in season 19, to see whether local gains survive a network.

The simulated link, stated plainly. The remote workload does not use a network. A small REST server, written for the judge with Go's standard library, runs on the same machine and is reached through a unix socket. It delays every request by a fixed 30 ms, delivers bytes at 48 MiB/s per connection and serves 5 requests at a time. The delays are sleeps on a schedule. There is no jitter, no loss, no congestion, no TLS and no object-store behaviour. It answers one question, whether a change costs requests or bytes, and says nothing about any real storage service. On the first version of the link (12 MiB/s), the tree after season 17 was 3.25% faster than upstream where it was 27.61% faster locally. With the remote workload in the score, one season moved it from 8.83% to 18.37%.

Noise, and how it was handled

Null calibration. The judge was run with three identical builds as its three arms. Whatever difference it reports between them is noise. In the first null (24 September 2026, 18 rounds) the paired difference in time had a standard deviation of 1.11% per round and peak memory 2.22%. The gates were set from it: a tree with no real change passes "ahead in 29 of 42, median at least 0.25%" about 1.2% of the time. The null was run again on 3 October 2026, after the judge machine moved to a fixed CPU frequency policy: time noise fell to 0.27% per round, a standard error of 0.05% on the median of 42 rounds, while memory noise stayed at 2.48%. On the remote workload the null read 0.42% per round (48 identical pairs).

The judge was also shown an effect of known size: a build with a deliberate 150 ms sleep and 24 MiB of extra memory in restore. By construction that is −2.2% on that command; the judge measured −2.04%, and the other six commands stayed inside their noise.

Screens that inverted at confirmation. A screen of 6 rounds ranks trees; it does not measure them. The league learned that three times before it changed its procedure.

The rescreen was added in season 13 for this reason, and in season 17 it changed which tree was confirmed. No number on this page is a screen quoted as a result.

Two jobs side by side. In the last season, prune on the big-index workload read three to four times larger when a second judge job ran on the machine at the same time: +22.54% in a match and +23.83% at the rescreen, both beside another job, then +6.70% in the 44-round job, which ran alone. Another team's tree read +22.51% beside a job and +4.75% alone. Check on the same workload did not move (+13.57%, +12.56%, +13.88%). The job behind the tables above ran alone on its lanes.

Binary layout. The same source can run at two speeds. restic derives its key at the start of every process. The inner loop of that derivation is about 3% slower when the linker places it at one of two alignments. Code added earlier in the binary can move it. It showed up as a listing command reading −1.65% (ahead in 0 of 3 rounds) in a tree that had changed no listing code: about 7 ms in every process, worth up to 0.9 suite points. The merge checked the alignment of the judged build and restored the fast one.

Stalls. On lanes shared with other work, 2 of 504 null runs took about 2.5 s longer than their siblings. Medians ignore them; a single reading that is off by seconds was treated as a stall and repeated.

The held-out workload

A fifth workload was held out. The teams could not select it, and its generator, seed and location are not published. An audit of the teams' transcripts found 7 sightings of its directory name in season 17, all in directory listings, and no recorded reading of its contents. After season 17 it was kept off the judge machine while seasons ran, and the transcripts were searched again before each test. It was run only at season boundaries, by the coordinator. Its results are above.

Speed maps that aimed the seasons

Unaimed search stalled within three seasons. What restarted it each time was a map. Before a season, the incumbent was profiled on the judge's own workloads, the time of each command was broken down by cause, and candidate changes were prototyped just far enough to measure their size. The teams received the map and a menu with measured sizes, not instructions. 10 maps were made. The first, before season 4, showed that about a fifth of the workload was start-up cost paid by every process; that season promoted +5.25% after two seasons that had promoted nothing. The second, before season 8, preceded the largest single step, +8.42%. When a season ran on a stale map, its first matches were noise.

Hand merges

One tree is promoted per season, so judged work by the other teams is left behind. An automatic merge of the best trees per command was tried in 4 seasons and merged nothing: the teams' trees edited the same files. So at three season boundaries a merge agent ported unpromoted ideas onto the incumbent by hand, one at a time, measuring each, and the merged tree went through the same confirmation as any candidate: after season 4; after season 17 (+6.06%, ahead in 33 of 42); and after season 19 (+1.14%, 36 of 44). The published tree is a fourth hand merge: the repaired tree, the sound part of season 20 and four ports from unpromoted trees.

Soundness

What was checked, and what was found.

A backup program that is fast and wrong is worse than a slow one. The judge compares results, and its warm-up tests a deliberately corrupted pack. It does not exercise two commands working on one repository at once, storage that is damaged while a command runs, or uploads that block. Those were examined by the later reviews and checks. So after season 19 the league's tree was reviewed for soundness before anything was published.

The soundness reviews

Three independent reviewer agents read every changed file of the league tree against upstream: the storage core (34 mechanisms), the backup side (21) and the read side (26). For each defect they wrote a test that reproduces it. Together they made 81 mechanism assessments. Counting a finding shared by several reviewers once, R1 to R11 are 1 blocker, 1 high, 7 medium, 1 low and 1 coverage finding; a memory finding, M22, is separate. None of the three found a weakened hash, MAC or verification, or a change to the repository format, to chunk boundaries or to tree encoding. A fourth review covered what season 20 added (16 mechanisms). A fifth covered the final merge (16 commits): it found nothing above low, and all 17 deliberate mutations the reviewer made to the merged code were caught by the tree's own tests.

The lock-wait defect

restic writes a lock file, waits 200 ms, and looks again for a conflicting lock from another process. From season 13 the league's trees used that wait: they read the snapshot list and the index during it, and kept what they had read. If another process's exclusive work, a prune, completed inside the window, a backup could deduplicate against packs the prune had just deleted. The backup then reported success, and its snapshot pointed at data that no longer existed. All three reviewers found it independently. None of upstream's tests could see it: upstream's integration tests set the lock wait to zero, which switched the league's wait work off.

The repair narrows the assumption. For commands other than check, an index read during the lock wait is used only if a listing taken at upstream's normal point, after the lock is confirmed, still shows its name and size. Index files that were added are loaded, and any removal discards what was read and reloads in upstream's order. Check reads nothing during the wait. Two cases remain and are listed under known limits: damage on storage that does not change a file's length, and a listing that still shows a file after it was deleted. On 3,000 randomised schedules the unrepaired code failed 163 and the repaired code 0. The defect was then reproduced with real binaries.

The defect needed a lock-file write slower than the wait: a remote backend, a retried save, a stall. The trials forced that by holding the write back for 300 to 3,000 ms. On a local disk under no load it may never have fired. It was a defect of the league's work and was never in upstream restic.

Ten more findings

The reviews also recorded a memory finding (M22): restore kept memory for every directory it visited. It was repaired in part, and the release checks found the rest (F5, below).

What was left out of the last season

The tree promoted in season 20 added three new mechanisms inside the lock wait: backup prepared compressed chunks, check read one pack, and restore read the snapshot and its trees. The review found that each was a new entrance to the same defect, and more. The backup one opened every entry of the backup source before the lock was confirmed, named pipes and device nodes included: 3 such opens per backup were counted, against 0 for the published tree. The check one certified a pack from bytes read before the lock, guarded by file-system notifications that network mounts do not deliver. Measured against the same tree without them, the three together cost 0.14 suite points. None of them is in the published tree. The index-side work in check and prune, which carried that season's gain, was judged sound and kept.

Release checks

A check agent then attacked the tree with real binaries on Linux: the tree's own tests and upstream's, the race detector, kills and interrupts in the middle of backup and prune, failing backends, corrupted packs, cross-reading with upstream in both directions, special files, and scale. The checks found 4 real failures, and all were fixed.

The whole set was run again after the last fixes. All 16 release checks pass on the judged commit. On the published commit, which differs from the judged commit by one comment and one test, the difference between the two source trees was checked and the added test was run, plain and 3 times under the race detector.

Three cases were added for that run:

• A kept index file damaged before prune's rewrite. Upstream and this build both stop with the same error, and upstream's check reports the same lines for both.
• A damaged blob while uploads are held. In 7 of 7 trials prune returned the error by itself instead of waiting.
• Copy with failing source packs and a stalled destination. 6 of 6 runs returned the error in about 1 s.

The checks also recorded one performance observation, on restores of very many directories with many CPUs. It is listed under known limits.

An independent review of the finished tree

After the release checks, 3 more reviewers looked at the tree (the "red team"). They were of a different model family from every agent that had built, repaired or reviewed it. They were given only two source trees, upstream's and the candidate's, and a strict contract for the candidate: nothing stored differently from upstream, no integrity check missing, the same behaviour and defaults, safe with concurrent processes and when killed, no data loss, exact restores. They were told to find any situation in which the tree would not meet the contract. They were not shown the earlier reviews or the repairs. Each worked for about 40 minutes and wrote a test for everything it reported.

No reviewer found data loss, a wrong restore, or an incomplete backup reported as a success. They reported 13 findings, 12 of them distinct, shown below in 11 rows. 5 findings carried the label "blocker" because the brief defined a missing integrity check as one: each is a place where the tree read once, or did not bound, something upstream reads twice or bounds. Of the 11 rows, 9 were fixed before the final measurement (one of them in part), each with the reviewer's test kept as a regression test. 2 are differences from upstream that are kept and documented.

The 11 commits that followed (the fixes, a change to restores of many directories, and the version string) were reviewed in turn by another independent reviewer agent. It found nothing above low severity. It made 25 deliberate mutations to the fixes; the tree's tests caught 23, and the two misses led to 1 more test. It also stated one limit of the lock-wait validation more exactly than before: the listing limit under known limits.

The limits of this review: one workstation, no race detector, no real backend with lagging listings, no runs with several processes, and about 40 minutes per reviewer.

What remains unknown

• No person has audited this code. The reviews were done by AI agents. They find what they look for, and the absence of a finding is not a proof.
• Other operating systems. Nothing was run on macOS or the BSDs. On Windows only upstream's tests and the reviewers' tests ran, on an unprivileged account.
• Real storage services. The tests used local repositories, the judge's REST server and SFTP. No cloud backend was used in any test.
• Long use. Nobody has run this build for months against one repository.
• Very large repositories. The scale check loaded a synthetic index of 30 million invented entries with no data behind them. No fully populated repository of that size was restored, pruned or checked.

Published with it

The instruments are in the repository.

The final judge result files, the sources of the judge and the workloads, the release-check harness, the review reports and the per-pair files of the many-core bench are published beside the source. The result files of the twenty seasons' confirmations and of the hand merges are not included: their numbers are quoted from the season reviews and the merge reports.

The judge and its workloads ↗

The program that builds the three arms, runs the paired rounds in a sandbox, checks every result against upstream and writes the result file this page is generated from; the workload generator; and the REST server with the simulated link. league/tools/judge

The research tools ↗

The quick bench, the timeline and the parity and memory tools the teams used between judged matches. league/tools/research-tools

The release-check harness ↗

The scripts behind checks C01 to C16, including the real-binary reproduction of the lock-wait defect. league/tools/checks

The merge, bench and release tools ↗

The tools of the final merge, the many-core bench, the binary-layout check and the release build. league/tools/merge

The launcher ↗

The league's configuration as it ran. It is a record: it needs engine modules that are not included and does not run on its own. league/tools/league

The patch series ↗

One patch for the league's tree after season 19, then one per later commit: the repairs, the merge and the fixes. league/series

Result files ↗

The judge's result files for the final jobs, the per-pair files of the many-core bench, the check tables and the held-out result notes. league/evidence

The league's own documents ↗

Scrubbed copies of the season reviews, the soundness reviews, the independent review and its triage, the merge reports, the check logs and the speed maps. league/reviews

The repository's own documents carry more detail than this page: Results, Methods, Soundness, Red team, Known limits, Tools, Changes.

Known limits

What this does not show.

• One machine, one architecture, 4 CPUs. Every timing in the league's results comes from one Linux machine (amd64), with 4 pinned CPUs per judge job and the corpus, repositories and restore targets in memory (tmpfs). Disk and real-network performance were not measured. Percentages can change with storage cost, latency and backend behaviour: measure your workload.
• Full clock. Every league timing, the final 44 rounds included, ran with the CPUs set to the performance frequency governor, which holds them at full clock. Most machines run a governor that follows the load.
• More than 4 CPUs. Every league number was measured with 4 pinned CPUs. A later bench of the published machine code at 8 and 16 cores, 5 fixed pairs per cell, found all 56 cells ahead of upstream; the smallest is remote check-read-data at 16 cores, +5.51%. Those are bench estimates, not judge scores. In restore, forget-prune and ls this build uses more user CPU than upstream, and the gap widens with the number of cores.
• Many directories on many CPUs. For a restore that is almost only directories, on a machine with many CPUs under a load-following frequency governor (the usual setting), this build was 4.8 to 10.7% slower than upstream in 4 readings. On 4 cores under the same governor it was 26.8% faster, and with the CPUs held at full clock it was 16 to 18% faster. The measurements, upstream against this build, on the release-check CPUs: 606,060 directories and 3 files, three rotated rounds. Load-following governor, with the official judge job running beside it: 16 CPUs 67.2 s against 74.0 s (10.1% slower); 4 cores 86.5 s against 63.3 s (26.8% faster). The same CPUs held at full clock: 16 CPUs 53.3 s against 44.7 s (16.1% faster); 4 cores 53.5 s against 44.1 s (17.6% faster). Load-following governor again, on a quiet machine: 16 CPUs 68.0 s against 75.3 s (10.7% slower). Larger snapshots under the load-following governor with 16 CPUs: 1,010,100 directories, 7.8% slower (three rounds); 2,020,200 directories, 4.8% slower (one run per build). What this settles: holding the CPUs at full clock removes the loss, and a quiet machine does not. The cache layout was ruled out before: at full clock, on eight cores spread over four cache domains, the same restore was 16 to 17% faster than upstream. So the judge job that ran beside the first measurement did not cause the loss. In the quiet run the mean clock of the running CPUs was 2.55 GHz for upstream and 2.02 GHz for this build, and the CPU seconds were 71.4 against 98.7; at the fixed clock both used about 55. That this build spreads the work over more threads, so that the governor sees less load per CPU and keeps the clock low, is an inference from the clock readings and the CPU seconds, not a measurement. Restore reads trees ahead for the first 524,288 directories of a snapshot and no further.
• The lock-wait validation is a listing. For commands other than check, an index kept from the lock wait is validated by a listing (name and size) after the lock is confirmed, not by reading the files again. On a backend whose listing can still show a file after it was deleted (a directory cache on a network mount, an eventually consistent store), an index file that a concurrent prune has deleted is not noticed. A backup can then deduplicate against packs the prune just deleted, and report success. It needs two things at once: a lock-file write slow enough for the prune to finish inside the wait, and a listing that lags the deletion. Upstream restic with the old index file in its local cache, which is the default after a first run, goes on with the stale index in the same way. Without a cached copy it fails loudly, because it tries to read the file.
• Damage of the same length inside the wait. For backup, restore, ls, forget and prune, an index file is not noticed by that run if it is changed in place on storage without changing its length, after this build read it during the lock wait and before the lock is confirmed. The window is 200 ms plus the time the lock file takes to write. No restic process can cause it: index files are never rewritten in place. Upstream notices such damage only if it reads the damaged file from the backend and not a valid copy from its local cache. A change of length is detected, and check is not affected.
• Restore reuses directory trees it has verified. Restore keeps complete, verified directory trees from its first pass, within a budget of 512 KiB of decoded nodes, and uses them in its second pass; other trees are loaded again. If storage damages a kept tree between the two passes, this build can finish from the valid copy it kept. Upstream fails when its second load reaches the damaged storage; a valid local cache can hide the same damage from upstream too. What is restored is the snapshot's content.
• Index and lock files are encoded differently. They decode to the same content and are valid Zstandard that upstream reads, but the compressed bytes differ by a few bytes from upstream's. Chunking, blob IDs and the stored form of data and tree blobs are upstream's.
• Three smaller differences. The review of the fixes recorded them. One message about clearing the local cache can be printed before a lock is refused, where upstream prints only the lock error. The ceiling on decoded size in check --read-data is the constant 64 GiB, upstream's default. When a write error falls inside a message that spans a flush of the output, the rest of the message is written where upstream gives the whole message up.
• The remote workload is a simulation. It is a small REST server with a fixed 30 ms delay per request, 48 MiB/s per connection and 5 connections. It is not a real network, and no cloud storage service was measured.
• Cold cache. Every phase starts with an empty local cache. Warm-cache repeat backups were not measured as a phase of their own.
• Linux is the only tested platform. All timing and all release checks ran on Linux (amd64). On Windows the tree was tested only as far as upstream's own tests and the reviewers' tests run on an unprivileged account: no shadow-copy backups, no elevated runs, no timing, no release checks. On macOS, the BSDs and the other targets nothing was run. All 25 of upstream's release targets built on an earlier tree. From the published commit five release targets were built: Linux and macOS for x86-64 and arm64, and Windows for x86-64. The other targets have not been built from it.
• It would not have been promoted. The published tree is slower than the league's last champion and uses more memory than it, while using less of both than upstream. By the league's own rules it would not have replaced the champion. The difference is the price of the correctness repairs and of the fixes from the independent review; the figures are in the results above.
• The held-out workload was not run on the published tree. The last tree measured on it is the one after season 19.
• The repairs cost requests on remote repositories. After the lock is confirmed, each process lists snapshots and index files again: one or two more requests per process, 29 to 63 ms at 30 ms per request.
• Binary layout. The key derivation's inner loop is about 3% slower when the compiler places it at one of two alignments. The judged Linux build is on the fast one. A build for another platform, or with another toolchain, lands where it lands: about 7 ms per process either way.
• Real storage services. No cloud storage service was used in any measurement or check. Several upload failures at once on a real service were not exercised for the reworked repack loop.
• Scale. The scale check restored a 50 GiB sparse file and loaded a synthetic index of up to 30 million invented entries, with no data packs behind them, during a small backup. It does not test a 50 GiB file of incompressible data, or a fully populated repository of that size being restored, pruned or checked.
• Other tools. rustic, Kopia and Borg were measured once, against the tree after season 15, on one workload. They were not measured against the published tree.
• self-update installs upstream. The build reports its version as 0.19.1-dev-dealer.1, and snapshots it writes carry that string as their program version. Do not run restic self-update with it: that command fetches upstream restic's release binary and would replace this build.
• Some error messages still point at upstream. Eight error messages inherited from upstream still tell the user to open an issue with the restic project. They are unchanged in this release, because changing them would change the binary after it was judged, reviewed and checked. For this build always report at the Dealer Style Restic issues page, never to upstream.
• No support, no audit by people. The reviews, repairs, merge and release checks described here were done by AI agents under one operator's direction. No human security audit has been done. The restic project has not reviewed or endorsed any of it.

Source and verification

Build it. Verify it.

It needs Go 1.25.8 or later, as upstream does; the judge built with go1.27.0. Use go build as shown: upstream's build.go script passes a version flag for a symbol this tree no longer has.

git clone https://github.com/slopdealer/Dealer-Style-Restic
cd Dealer-Style-Restic
go build ./cmd/restic
./restic version

The build reports its version as 0.19.1-dev-dealer.1. Do not run restic self-update with this build. That command fetches upstream restic's release and would replace this binary with upstream's.

Then verify it on a test repository before anything else. Upstream restic is the referee: it must accept what this build wrote.

./restic init --repo /tmp/dsr-test
./restic --repo /tmp/dsr-test backup /path/to/a/copy/of/real/data
restic   --repo /tmp/dsr-test check --read-data     # upstream restic checks what this build wrote
./restic --repo /tmp/dsr-test restore latest --target /tmp/dsr-restore
diff -r /path/to/a/copy/of/real/data /tmp/dsr-restore/path/to/a/copy/of/real/data

To repeat the measurements, start at METHODS.md: the judge, the workload generator and the instructions are in the repository. Your files, your storage and your CPU count will move the result; measure before you rely on it.

Downloads and checksums

The release also carries SHA256SUMS and restic's unchanged LICENSE. An independent rebuild from the published source, with the documented command, reproduced all 5 binaries bit for bit.

What these binaries are, exactly. The published source builds to the judged machine code byte for byte: the two builds differ in 60 bytes, all inside build-ID notes. The release binaries are that build with the version string set: the same instructions at the same addresses, with different address operands. They were not themselves judged. One timing comparison of one command was made over 20 fixed pairs, and it resolved no difference.

An independent Slop Dealer build. restic is distributed under the BSD-2-Clause licence, and this derivative keeps it. Report problems with this build to its own repository, not to the restic project.