This is an administration task, and the sql standard does not define such things; so a DBMS is not required to have this. But since it is obviously very useful to be able to make a backup, most systems do have similar capabilities, although they might be implemented or named in a different way.
The corresponding function to the "simple" recovery model is a mysqldump or a pg_dump.
An equivalent to the transaction log backups which will be created in the mssql-"full" recovery model are the mysql binary log and the WAL-log for postgres. All methods will allow you to continuously backup and (more or less comfortably) recover a database to a point after the last complete backup. Many technical details, e.g. on how to recover, if the file created by the "simple" backup can be used for it, the file formats, or how or if the files used internally (e.g. after a crash) differ.
These methods also resemble each other in that they will be used (and are required) for replication purposes in all three database systems. For such a functionality, a different server needs to be continuously informed about all the changes that oocured, which is exactly what these logs contain.
For the MSSQL-"Bulk logged" recovery model, there is no direct equivalent; it is a special version of the "full" model that does not log some bulk operations.
