Judging from a quick search in the forum and the github bugtracker you’re the first to report that crash.
Is that crash reproducible? If yes, you could run the backup in verbose mode restic backup -vv to find out which file is causing the crash? For debugging it would be helpful to use a restic binary built with go >= 1.13 which would also print which slice boundaries were used.
Thanks for the reply, so i reran manually but this time no error im going to wait until the cronjob does it automatic and see if it happens again ill post back
@fd0 and me had a really close look at the chunker function, but we couldn’t find anything pointing towards a bug in the chunker code.
The crash rather looks like a bit-flip in memory, so you might want to run a memcheck.
Thanks for the reply, @killmasta93 so what i did find out was that again i was getting that error, when i checked the logs restic was running at the same time as the vz dumps (running proxmox) which causes i think a panic but the dump was running the same VM which is backing up the files, i turned it off to see and it worked flawless but thanks again
Thanks for the replies, @farzadha2 i changed the vz dumps to do later after restic does the backup and so far so good @fd0 i will postback this week if i get the error again thank you again for everything
The error looks like io.ReadFull(c.rd, buf[:]) returned a negative length (at least that’s the only sensible explanation I see how that slice index got that large). When interpreted as a negative number the length would be -13 (restic casts the length to an uint). Problem is that ReadFull should never return any length below zero. Maybe that’s happening nonetheless .
@killmasta93 Which type of filesystem do you backup? Taking half an hour to list 1.5 million files looks rather slow to me. Do you know/have an idea which file causes restic to crash?
Thanks for the reply, currently backing up file shares on a window server which i mount it on CIFS on proxmox and the NAS so i can run restic on proxmox to backup the windows server files. i think whats odd is that on a previous post at first its really fast then it gets slow as you mention. But if i run restic manually i get no issue its sometimes this issue when i run using rescript so odd
Thank you very much! Something odd is going on here, I agree with @MichaelEischer that apparently io.ReadFull() returned a negative number of bytes. That should not happen.
Can you maybe apply the following patch and see if it appears again?
The only explanation I currently have is that the file system you’re reading data from returns odd values. io.ReadFull() is a thin wrapper around the read syscall, which according to the man page does not return negative values other than -1 to signal an error…