I am having issues with files being backed up from my windows 2019 server to a ReadyNAS 316.
Nothing shows up in the log and only some files seam to be the issue. In the example below I am showing JPG files that have a zero file size once they are copied from the server to the NAS.
Firmware version is 6.10.5 hotfix 1
Model: RN31600|ReadyNAS 300 Series 6- Bay (Diskless)
Copying from the server to the NAS work fine. I have been using a software call beyond comapre to reconcile the files that are not baking up correctly. The back job is using the built in backup utility on the Readynas using the windows timestamp.
The back job is using the built in backup utility on the Readynas using the windows timestamp.
You reported this a couple months ago, but we never isolated the root cause.
Personally I use backup tools on the PCs that have the NAS as a destination, and don't use the backup utility for this. I do use backup jobs for NAS-NAS, and they use rsync.
I am digging a little deaper before downgrading the firmware. I have over 25Tb of data on there and I need to make sure everything is backed up just incase.
While I am backing stuff up to other divices I created some smaller backup jobs that I can run multipule times to see what settings effect if the Zero file size comes back.
So far I have seen the inital full backup that removes the contences of the desination folder will create the Zero file size files. After running an incramental backup all of the zero file size files are copied correctly. Then I would do a 3rd backup that is a full backup again with the setting to "remove contense of the backup destination before full backup". All of the same Zero file size files would return.
The left side if the source and the Right side is the destination. Each of the screen shots were taken right after each of the backup jobs were complete.
So far I have seen the inital full backup that removes the contences of the desination folder will create the Zero file size files. After running an incramental backup all of the zero file size files are copied correctly. Then I would do a 3rd backup that is a full backup again with the setting to "remove contense of the backup destination before full backup". All of the same Zero file size files would return.
Interesting. Do you need that "remove contents" option?
So far I have seen the inital full backup that removes the contences of the desination folder will create the Zero file size files. After running an incramental backup all of the zero file size files are copied correctly. Then I would do a 3rd backup that is a full backup again with the setting to "remove contense of the backup destination before full backup". All of the same Zero file size files would return.
Interesting. Do you need that "remove contents" option?
Yes, The option cleans up files that have been renamed or moved. I usally have it set to do a full backup every 4 weeks.
Yes, The option cleans up files that have been renamed or moved. I usally have it set to do a full backup every 4 weeks.
Rsync has the option to delete files that are no longer on the source. There are some third-party rsync servers for Windows, so you could maybe install one of those, and see if you can switch to rsync and not use smb.
But I am wondering what happens if you manually delete the backup contents, and then run the normal incremental backup. Does that also give you the 0-length files?
It is curious that you never see them after the incremental backup - I'm not certain that is 100% true, it might just be because the incremental backups aren't copying as much stuff.
I have tried manually deleting the contents of the destination and I get the same results every time I do a full backup with the "delete contents" option enabled. I have even created a new share and copied about 200Mb of data do it to do some testing. The incremental backups will always replace the Zero file site files and any other files I update on the Source location.
I have tried manually deleting the contents of the destination and I get the same results every time I do a full backup with the "delete contents" option enabled.
But happens if you manually delete everything in the destination folder, and then run the incremental backup??? Are you saying you get the same result (zero-length files)? Not clear from your response.
The incremental backups will always replace the Zero file site files and any other files I update on the Source location.
Ok, so there is a potential workaround, which is to immediately run an incremental "cleanup" backup after every regular backup. Schedule one job that does a full backup (deleting contents) once a month - say at 0100, and then schedule a second job at 0200 that is always incremental. If the regular job is still running, the cleanup job will be queued until the first job finishes.
I have tried manually deleting the contents of the destination and I get the same results every time I do a full backup with the "delete contents" option enabled.
But happens if you manually delete everything in the destination folder, and then run the incremental backup??? Are you saying you get the same result (zero-length files)? Not clear from your response.
Sorry, Yes I get the same Zero file size files. Not alwasy the same files, but it looks like PDF's, JPG's, and DOCX files are the most commen.
I will try the Full backup & Incremental backup as two diffrent jobs and see if I get better results.
I have downgraded to FM: 6.10.1. Now at at least get backup errors when the zero file site files are created.
I get this message at the bottom of the log, but I don't see any indications of why it failed. If I re-run the job as an incremental job I don't get the error.
Full backup with "Delete contenct" option
Backup Job Type: Full Protocol: cifs-ab
Backup Start Time: Mon Aug 30 2021 2:47:01 PM Backup Finish Time: Mon Aug 30 2021 3:04:17 PM Backup Status: Fail: Failure during copy.
I get this message at the bottom of the log, but I don't see any indications of why it failed. If I re-run the job as an incremental job I don't get the error.
Have you looked in system.log? Maybe also smbd.log.
Is it possible that someone modified the samba configuration on the NAS? There is no parameter called "smb signing" in samba (there are are a couple of parameters related to signing, but they are not called that).
Aug 30 08:28:39 xxxx dbus[3231]: [system] Activating service name='org.opensuse.Snapper' (using servicehelper) Aug 30 08:28:39 xxxx dbus[3231]: [system] Successfully activated service 'org.opensuse.Snapper' Aug 30 08:28:41 xxxx snapperd[29722]: loading 7815 failed Aug 30 08:28:41 xxxx snapperd[29722]: loading 11346 failed Aug 30 08:28:42 xxxx snapperd[29722]: loading 7225 failed Aug 30 08:28:42 xxxx snapperd[29722]: loading 10756 failed
Snapper manages the system snapshot feature, and (as you might expect) the error is that some snapshots the system thinks exist cannot be loaded. A BTRFS scrub might clean this up (not sure). It would take a while to run (generally days), and it shouldn't be related to your problem.
BTW, do you have snapshots enabled on the NAS share used for the backup?
/lib/param/loadparm.c is part of the source code for SAMBA. Do you know how that got to be on your NAS? It's not standard.
It looks like it's just a C assertion being logged - which do include the source file and line number. No reason to think that loadparam.c is on the NAS.
