Sparse files may be expanded on copy when the -S flag is not used. (Will make the destination take more space)
Hard links within the tree may be expanded to separate files on copy when the -H flag is not used. (Will make the destination take more space)
Filesystems may have different allocation sizes. A one-byte file may take up 512 bytes of disk ...
If you want to be on the really safe side (depending on your level of paranoia):
Burn in the new device
Perform surface test of new device
Copy files to new device (i.e. not using the option --remove-source-files)
Mount the new device in its intended place and make sure everything works correctly
Only when everything works fine, discard the source files.
You can match these files with a simple shell glob, and the --relative (-R) flag to maintain file paths in the destination:
rsync -avR src/./201?/*bbb*.pdf dst/
Example run using your data
rsync -avR src/./201?/*bbb* dst/
created directory dst
sending incremental file list
The lsync daemon uses rsync as a backend, but uses inotify to only sync files/directories that change (after an initial full pass). I'm not sure if it will scale to your size, but we've used that to replicate structures in the 1-2 TB region with very little problem.
Group www-data does not have write permission.
( you state it has permissions drwxr-xr-x www-data:www-data )
You need to (at least) give write permission to this group (sudo --user www-data chmod -R g+w /var/www/mysite.com).
In addition I would consider using file access control lists (with default permissions), to ensure that group www-data retains ...