In your answer, you write, "I read that ._ files are used to store information that would go into a HFS+ extended attribute. As I'm copying between HFS+ drives I figured I don't need these files."
I would not make this assumption without further testing. It is not necessary that the resource fork information captured in these existing dot bar files has been (re-)incorporated (back) into the associated file.
There is a Wikipedia article on "AppleSingle and AppleDouble formats":
The "dot bar" files can be created under a number of cases, for example, see:
Why are dot underscore ._ files created, and how can I avoid them?
The question whether the dot bar files should be re-incorporated was discussed here:
How should I reconcile dot-underscore files after a manual backup?
The OS X/macOS command
dot_clean has a number of options regarding how to deal with them:
The default option. If an attribute is associated with a data fork, use that. Otherwise, use information stored in the AppleDouble file. Note that the native fork's data is preferred even if the data in the AppleDouble file is newer.
Always use information stored in the AppleDouble file, replacing any extended attributes associated with the native file.
Always use the information associated with the data fork, ignoring any AppleDouble files.
You can consult
man dot_clean for further information and options.
You might remove some uncertainty by determining whether the files with an associated dot bar have any resource fork information attached without reference to the dot bar files. This might be somewhat involved to test, as copying the files might re-incorporate the dot bar files during the copy.
You may not care, or may not care to spend the time to determine, and simply run dot_clean with its default option.
Or, you could ignore the issue for now and not exclude the dot bar files during your rsync backups.
It should be pointed out that much of this discussion is in regards to how to treat the source/origin of the backup. Presumably, the purpose of a backup is to duplicate as exactly as possible the source. As such, I would not exclude the dot bar files as part of your backup. Instead, I would look to the reason the dot bar files exist in your source. Then, whether, and later how, to "fix" them.