I would like to replace my node’s HDD with a larger one while the system is still running. As we all know, this process can take a long time—and on a Raspberry Pi, it takes even longer. Has anyone found a method that minimizes downtime while ensuring the files are transferred securely? Alternatively, does anyone have experience with a setup like mine: a Pi 4 connected to a powered external HDD via USB 3, with a new powered external HDD connected to the second USB 3 port (the blue one)?
Just the normal way: rsync from disk A (have data) to disk B, (optionally do it again) then stop docker, run a final rsync from disk A to B again, then run docker from disk B. If you done it right, it should take less than 10 minutes downtime.
P/s: there a lot of tutorial about that, search the forum to have the exact command.
If possible clone HDD or copy entire partition.
Rsync is painfully slow with millions of small files. If there is no other way you might consider doing conversion to hashstore first. Rsync is much faster with hashstores 1 GB files.
This describes the process, suggested by @kocoten1992 in details:
One additional note - you can reduce the allocation below the usage before migration, this will stop any new ingress, so the sequential rsync will be shorter.
Also - the last rsync must be done with the stopped node and the --delete flag, otherwise your databases could be corrupted.
The fastest method is suggested by @alpharabbit, but it will be with a downtime.
You may also use integrated features of ZFS or LVM if you use them.
Some reported, that using rclone instead of rsync was faster for them.
you could migrate fully to hashstore first. Then you copy in 1GB chunks which is faster. That migration would take super long in itself though.
In my experience rclone was a bit faster than rsync. like 50% faster of very slow is still “very slow”.
That’s because rsync by default does a lot more validation and safety than rclone. If you want the same behavior as rclone do
rsync -a --whole-file --inplace --no-compress --info=progress2 SRC/ DST/
Bit for node migration both are suboptimal: stop the node, then stream entire partition/dataset/subvolume/filesystem in one sequential operation
If the source is on LVM, make the destination join the same volume group, and do pvmove.
If the source is not on LVM, this is your opportunity to start using LVM on the target 
pvmove is nice indeed.
Another similar migration path exists with ZFS, btrfs, or mdadm: add the new disk as a mirror member, let it sync/resilver, then remove the old disk.
This is anothet illustration against putting filesystems directly on plain single disks in modern day and age. No useful migration machinery among other drawbacks, for no benefits in return.
Always use sone storage-management layer below the filesystem, even if there is only one disk today. Tomorrow that may — and often does — change.
It’s useful even for a one disk systems too, exactly because of easy of migration in the future or to spare a part of this disk for something else.
So I would like to generalize - for more powerful systems it’s better to use ZFS, for less powerful - LVM. BTRFS I wouldn’t suggest for consideration, at least for storagenode (maybe it’s ok now for hashstore? 
).