TOS5 - USB copy, TFM backupp - Partially succeeded

[Herbertson]

Hello,

I'm fresh owner of a F4-423 (TOS 5.1.67, 4x 4TB as TRAID and 2x 500GB NVMe SSD)
So far, so good

My issue for now ist, that some jobs within "USB copy" as well as "TFM backup" stopped sync/copy and alert that der job is only "partially succeeded"
If I start the related copy job manually again, the process first starts checking, but it will stopped over and over exactly after a same count of files.

In both apps the jobs are configured as mirrowed backups.
The destination volume is an single external USB harddrive (8TB, Exfat formatted).

What's going wrong here?
Thanks for help and the exchange of experiences.

Regards,
Herbertson

[TMzethar]

It is currently difficult to guess the specific reason.
You can extract logs from USB Copy and TFM, collect a system report on the TehcnicalSupport Report Issue, and provide them to our technical support email for review.
In addition, you can also check the hard drive or try manually copying to see if similar situations occur.

[Herbertson]

Hello TMzethar,

thanks for your response.
I will check the option with the log files – I just have another idea now.
Syncing via terminal by using the "ditto" command (macOS terminal).
The login via ssh works as expected, but which is the path to the usb drives?

Do you think this will work?

Thanks.

[Herbertson]

Related to this note…

Syncing via terminal by using the "ditto" command (macOS terminal).
The login via ssh works as expected, but which is the path to the usb drives?

… I've examine some own experiences now:

• The "ditto" command is not available within the TOS Linux system
• Instead I use "rsnyc command", like this:

  Code: Select all

  rsync --delete -azvv /Volume1/_JU-N1_/ /Volume1/\@usb/usbshare2/_JU-N1_/

Therefor I observed, that the file format of e.g. Apple Pages files are causes some errors.

• If the selected file format is set to "single file", rsync and the file manager of TOS5 handle such kind of files correctly as a file.
• If the selected file format is set to "package file", rsync and the file manager of TOS5 interpret such kind of files like a folders with sub content…

  Code: Select all

  _JUG-WW1/WW1-Orga.numbers
  rsync: [receiver] chown "/Volume1/@usb/usbshare2/_JU-N1_/_JUG-WW1/.WW1-Orga v1.numbers.qQrhTY" failed: Operation not permitted (1)
  _JUG-WW1/FHH…/
  rsync: [receiver] chown "/Volume1/@usb/usbshare2/_JU-N1_/_JUG-WW1/.WW1-Orga.numbers.Fs0Uls" failed: Operation not permitted (1)
  

Finally I observe that the follwoing errors are reported after a finished rsync process:

Code: Select all

total: matches=0  hash_hits=0  false_alarms=0 data=3479193
sent 1,956,166 bytes  received 2,819 bytes  559,710.00 bytes/sec
total size is 3,603,793  speedup is 1.84
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=3.2.3]

What should I think of that?
Is there a setting that ensure that TOS can handle the "Package" files properly?
Could this causes the reported problems with the app "USB copy" and/or "TFM backup"?

Thanks a lot.

[TMzethar]

The information you provided has been submitted to the relevant project team. If you have more relevant details, please provide them. If you have free time, you can also try the possibilities mentioned above.

[TMzethar]

What are the sizes of the source files? What are the sizes of the files you successfully backed up?

[Herbertson]

Hello,

As I just recognize, that the reason for such kind of copy errors could caused in the name of files – for example: "Y1U75N~Y.pdf"
As seen there is a "~" character within it.
But I'm not sure when it happend that and why some file names were changed like seen in the example.

If I remember correctly, it could be that I have activated the SMB option called "VFS-Modul" for converting macOS special characters within the TNAS preferences for the SMB file services for the initial copy process, from the external reference HDD to the TNAS.

Later I must have deactivated it, because I wasn't sure about it anymore. For now this option is "off".
Could it be, that this causes such kind of file renaming like shown in the example above?