The common name for the filesystem-level snapshot like that (and all of the WAL segments needed to restore it, as well) has the name – a “base backup”.
Something partially different than a physical backup is the SQL dump (or logical backup). As the name suggests, this backup is all about using PostgreSQL backup commands to create database’s basic structure and then fill it to the brim with data. An SQL dump consistently represents a calm state of the database at any given moment (since the “dumping” process is almost the same as any other database session).
The process goes like this: the software goes through all of the tables available and fetches all of the rows. It’s not really complicated, but it is smart enough to keep with the order of things to restore everything as it was backed up, with all the connections and such.
Using SQL dumps means that you’ll have to get used to the data from various tables being spread over the timeline. It means that one table can have a timestamp A, and the other one might be done at the timestamp B. This is useful to keep in mind in case there are any kinds of rules in the database about how rows and tables should interact with each other.