while btrfs certainly is a powerful modern fs the admin manual is vague and misleading in its recommendation of it. snapshots happen at the filesystem level and can only be taken of filesystem-subvolumes.
since i’ve had some unpleasant experiences with btrfs in production environments some time ago i still stick to ext4 (even on my SLES-servers); privately and on mission-un-critical stuff i use btrfs heavily.
for a snapshot-backup-scenario with nextcloud on btrfs i recommend using a separate subvol for both the nextcloud-webdir (where all the php-code etc is) and the nextcloud-datadir. that way you can easily make automated snapshots (but you have to take care of db-backups separately!).
(i think suse puts / and important dirs in subvols and their “snapper” takes snaps of those. since a btrfs-subvol can contain other subvols you probably cannot get rid of this in your nextcloud-dir if you want to use the suse-tool.)
if you want a snapshot-based roll-back for a failed nextcloud-upgrade you should probably do this with one snapshot of the whole system since the database also gets changed in a nextcloud-upgrade.
on the other hand, if you “just” need backups it’s much easier to use file-based tools like rsync, rsnapshot and mysqldump and store those backups on a different machine. if your disk/array containing all the btrfs-snapshots fails the snapshots won’t be of much use.