Dump file would be roughly the same. You'll have some extra revision properties on r0 that svnsync uses to keep track of it's source repository if you use svnsync.
Unless you have a small repo you're probably not going to want to do a svnrdump of the entire repo every time you take a backup. So that means you'll have to take and keep track of the backed up revisions and keep producing --incremental dumps. svnsync on the other hand you don't have to keep track of your revision stopping point it does that for you and each time you run sync it just pulls down the new revisions.
If you don't do a full dump with svnrdump (and only dump new revisions) any revision property changes won't be reflected in your dump (e.g. fixing a typo in svn:log on a a revision). svnsync allows this to be done by using the copy-revprops subcommand.
Both methods are not going to be complete backups however. locks are not reflected in the dump output (might not matter if you don't use locks). Nor will you get copies of your hook scripts and repository configuration files (though generally you don't change those after creation much if at all).
Alternative solutions would be svnadmin hotcopy (which has it's own issues with locks) or using svnadmin freeze and using filesystem snapshots of some sort. If you have full access to the server with the original, I'd suggest going this route since you'll have a more complete backup. Once the repo is duplicated (or a snap shot taken) with one of these techniques then you can use rsync (or whatever other tools you can't to use) of the copy (or snap shot) to a remote machine.
