When I back up code files on Windows, repository corruption occurs 100% of the time

I run Restic on Windows to send backups via the SMB protocol to a Samba server running on Linux.

After completing the backup, run restic check --read-data on the Linux server to discover that the backup is corrupted.

I deleted the entire backup and performed a new backup. After it finished, I checked again. The backup remains corrupted.

I suspect there’s an issue with the Samba protocol.

I tried installing rclone on Windows and attempted the backup again by connecting to the SMB server via rclone. When I verified it on the Linux server, the backup was still corrupted.

I backed up the entire hard drive, excluding some unused directories. It contains a large number of small files, totaling approximately 2TB.

For rapid testing, I converted the backup from the entire disk to backing up several block files. Each block file is around 100GB in size, totaling 500GB backed up. I verified the backup on the Linux server, and it was intact.

I’m not sure why.

#storage server
root@debian13:~# restic version
restic 0.18.0 compiled with go1.24.4 on linux/amd64
#backup server
C:\Users\lock>restic version
restic 0.18.1 compiled with go1.25.1 on windows/amd64
C:\Users\lock>rclone -V
rclone v1.71.2
- os/version: Microsoft Windows 10 Pro 22H2 22H2 (64 bit)
- os/kernel: 10.0.19045.6456 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.25.3
- go/linking: static
- go/tags: cmount

I use resticprofile to quickly execute backups.

version: '1'

global:
  prevent-sleep: true
  priority: background
  restic-binary: "C:\\Users\\lock\\.local\\bin\\restic.exe"
  restic-stale-lock-age: 24h

path-d:
  initialize: true
  lock: "D:\\Tools\\resticprofile\\resticprofile-windowsBackup.lock"
  force-inactive-lock: true
  repository: "rclone:smb:Main\\Backup\\restic-repo\\windows\\pathd"
  password-file: "D:\\Tools\\resticprofile\\restic-password.txt"
  pack-size: 64

  backup:
    source:
      - "D:\\code"
      - "D:\\Tools"
      - "D:\\WEB"
      - "D:\\system\\Users\\lock"
    use-fs-snapshot: true
    exclude-caches: true
    exclude-cloud-files: true
    iexclude:
      - "desktop.ini"
      - "thumbs.db"
      - ".venv"
      - "__pycache__"
      - "node_modules"
      - "OnlyFans/.sites/**"
      - "System Volume Information"
      - "Recovery"
      - "$$Recycle.Bin"
      - "found.000"
      - "RECYCLE"
      - "Tmp/**"
      - "Game/**"
      - "Python/**/venv/**"
      - "Anaconda3/**"
      - "WindowsApps"
      - "Photo Archive"
      - "Tencent Files"
      - "uv cache"
      - "Go/GOPATH/**"
      - "Disk Cache*/**"
      - "lock/Downloads/**"
      - "cache/**"
    tag:
      - '{{ .Profile.Name }}'
    run-before:
      - 'python d:/Tools/resticprofile/list_tree.py'
    schedule: '19:30'
    schedule-log: 'logs/{{ .Profile.Name }}-{{ .Now.Format "2006-01-02" }}.log'
    check-after: true

  retention:
    after-backup: true
    keep-daily: 5
    keep-weekly: 4
    keep-monthly: 3
    prune: true

  check:
    enable: true

  snapshots:
    latest: 15

My Samaba Server Configuration

services:
  samba:
    image: ghcr.io/servercontainers/samba:smbd-wsdd2-a3.22.2-s4.21.4-r4
    container_name: samba
    hostname: NAS02
    ports:
      - "139:139"
      - "445:445"
    cap_add:
      - CAP_NET_ADMIN
    environment:
      MODEL: "TimeCapsule"
      SAMBA_CONF_LOG_LEVEL: 3
      AVAHI_NAME: NAS02
      SAMBA_CONF_WORKGROUP: WORKGROUP
      SAMBA_CONF_SERVER_STRING: NAS02
      SAMBA_VOLUME_CONFIG_Download: "[Download]; path=/shares/Download; valid users = smb; guest ok = no; writable = yes; browseable = yes"
      SAMBA_VOLUME_CONFIG_Main: "[Main]; path=/shares/Main; valid users = smb; guest ok = no; writable = yes; browseable = yes"
      SAMBA_VOLUME_CONFIG_More: "[More]; path=/shares/More; valid users = smb; guest ok = no; writable = yes; browseable = yes"
      SAMBA_VOLUME_CONFIG_Temp: "[Temp]; path=/shares/Temp; valid users = smb; guest ok = no; writable = yes; browseable = yes"
      SAMBA_VOLUME_CONFIG_Web: "[Web]; path=/shares/Web; valid users = smb; guest ok = no; writable = yes; browseable = yes"
      ACCOUNT_smb: "passwd"
      UID_smb: 1001
      GROUPS_smb: users
      TZ: Asia/Shanghai
    volumes:
      - /mnt/Z2/Download:/shares/Download
      - /mnt/Z2/Main:/shares/Main
      - /mnt/Z2/More:/shares/More
      - /mnt/Z2/Temp:/shares/Temp
      - /mnt/Z2/Web:/shares/Web
    restart: unless-stopped

Update:

I switched to using REST HTTP as the transport protocol.

The issue persists—the verification repository is corrupted.

No errors occurred when backing up simple block files, but backing up the Code folder, which contains numerous libraries with many small files, resulted in problems.

I’m unsure where the problem lies.

services:
  restic-rest-server:
    image: restic/rest-server:0.14.0
    container_name: restic-rest-server
    restart: unless-stopped
    ports:
      - "20280:8000"
    volumes:
      - /mnt/Z2/Main/Backup/restic-repo/windows:/data

log

root@debian13:/data/docker/rest-server# restic check --read-data -r /mnt/Z2/Main/Backup/restic-repo/windows/path-d
using temporary cache in /tmp/restic-check-cache-902535056
create exclusive lock for repository

repository 065d31d2 opened (version 2, compression level auto)
created new cache in /tmp/restic-check-cache-902535056
load indexes
[0:00] 100.00%  6 / 6 index files loaded
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  1 / 1 snapshots
read all data
check successful on second attempt, original error pack be8aa63dfe7dbdb4a67f4cc3ed6b1d14ac51fa479759946a228338dd320b5636 contains 1 errors: [blob fdd39eceae4633dd7907832114dc1b09f77c7cb07a33643ac9cd75a816489cea: read blob <data/fdd39ece> from be8aa63d: wrong data returned, hash is 335fce8480ba1459197e71008b391563027b1868e4758f0e6c5f31559826a440]
[13:53] 100.00%  1120 / 1120 packs

The repository is damaged and must be repaired. Please follow the troubleshooting guide at https://restic.readthedocs.io/en/stable/077_troubleshooting.html .

Fatal: repository contains errors

Update:

I tried again and discovered some new information.

The files were sent from Windows to the Linux server.

I verified the backup on Windows without errors, but when verifying on the Linux server, it reported errors.

Another post has a similar error.

A warning when restoring from a different platform

PS D:\Tools\resticprofile> resticprofile path-d.check --read-data
2025/10/24 23:16:48 using configuration file: profiles.yaml
2025/10/24 23:16:48 profile 'path-d': initializing repository (if not existing)
2025/10/24 23:16:48 profile 'path-d': starting 'check'
using temporary cache in C:\Users\lock\AppData\Local\Temp\restic-check-cache-2553684235
create exclusive lock for repository
repository 065d31d2 opened (version 2, compression level auto)
created new cache in C:\Users\lock\AppData\Local\Temp\restic-check-cache-2553684235
load indexes
[0:00] 100.00%  7 / 7 index files loaded
check all packs
check snapshots, trees and blobs
[0:01] 100.00%  2 / 2 snapshots
read all data
[13:27] 100.00%  1122 / 1122 packs
no errors were found
2025/10/24 23:30:19 profile 'path-d': finished 'check'
root@debian13:/data# restic check --read-data -r /mnt/Z2/Main/Backup/restic-repo/windows/path-d
using temporary cache in /tmp/restic-check-cache-4161944301
create exclusive lock for repository
enter password for repository: 
repository 065d31d2 opened (version 2, compression level auto)
created new cache in /tmp/restic-check-cache-4161944301
load indexes
[0:00] 100.00%  7 / 7 index files loaded
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  2 / 2 snapshots
read all data
check successful on second attempt, original error pack 34cdf37e480ef1a10cb76c1f9b0d7a5ad45466fc1b562e096cefc4bc387f5a8d contains 1 errors: [blob 4509d54d121e844b18ba16bff071a51e68d1518af985210c07c08efcff23ddda: decrypting blob <data/4509d54d> from 34cdf37e failed: ciphertext verification failed]
[14:10] 100.00%  1122 / 1122 packs

The repository is damaged and must be repaired. Please follow the troubleshooting guide at https://restic.readthedocs.io/en/stable/077_troubleshooting.html .

Fatal: repository contains errors

Of course it is possible but given that it is widely used/tested/maintained protocol and its implementation I would be surprised if this is the case. And if yes then it has nothing to do with restic…

Try some other protocol - sftp should be the easiest I think as on Linux you can spin up server out of the box.

If issues persist then it would mean that most likely you have faulty hardware. First I would check RAM - run memtest for all night on both machines.

1 Like

Sorry, I think I miscommunicated. I was just suspecting Samba at the time. When I tested the backup block file and found no issues, the problem must lie elsewhere.
I’ll be testing using SFTP. Each backup takes 10 hours, and verifying the backup takes several more hours. I can only wait patiently.

1 Like