Choosing a filesystem, apart from the obvious technical features that you want to use is still a personal preference. You should also be aware that "self-healing" can only work when a BTRFS filesystem is assigned more than one drive and the meta/data storage is set accordingly. The most BTRFS can do reliably with a single drive is detect corruptions, and avoid using the corrupted parts of data any further. In the very limited case when the corruption is in the metadata, a second copy may be used to recover it, otherwise all you get is an I/O error and a kernel log entry. Please be aware though that metadata by default is NOT duplicated on SSDs, only on traditional drives.
It's also a good practice to use different filesystems for different types of data to avoid any kernel bugs to affect both drives; but again, BTRFS is famous for being able to detect environmental factors corrupting the data in previously unrecognized ways, so this could be an argument to use BTRFS on both places.
Using two different filesystems is also wise from the point of view that BTRFS was not the easiest to use on different platforms - if all your backups are on a portable drive with ext4, chances are you can easily access them anywhere else, but just the same, you can use any modern live CD to access BTRFS data
Just about the only drawback of a BTRFS backup drive is that if something is badly messed up, recovering just to access your data might be more complicated than an fsck, but due to the error detection, I've had great luck on a 3-drive RAID5 system where two drives started acting up simultaneously, and one of them actually dropped off the bus until a poweroff. With BTRFS, I was able to copy off most of my data, flagging the few unimportant recently changes files that were corrupt.
For any BTRFS user, the most useful part of having a BTRFS filesystem is quick snapshots, but they need to be managed manually, and you can run out of disk space if you use them with no consideration.
A further advantage of the the BTRFS snapshots is the incremental backup between them - i.e. if you make snapshots on subvolumes with very large files that have only few blocks of changes (i.e. lightly used VMs, some types of database files, mailbox archives), the incremental btrfs send can be used to reconstruct the few actual changes, instead of shipping entire files over; which would happen if you used rsync to copy snapshots to the cold drive.
But again, this is only an advantage if both the source and the destination of the backups are BTRFS.
One way around this would be to use BTRFS as the work drive, with snapshots used heavily, then using an external drive as ext2/ext3/ext4 only to store btrfs send images for full and frequent incremental backups; for data integrity, using hashes on the stored btrfs send files, and using something like par2 to generate additional parity to ensure recoverability from corrupted/deleted files.
This above could sound like my dream backup system, however, it's really cold store indeed - you cannot recover any part of data without reimporting it on a new BTRFS volume with sufficient space, and testing that the procedure is safe can be quite difficult or error-prone.
