The article written by Paul regarding backup internals is excellent one and you must read it. Adding to what others have said and emphasizing on specific part of your question
Also I heard that backing up is single threaded meaning it uses only one core, assuming you backup to a single file. Also assuming you have a multicore machine, for example 16 cores, or at least a significant larger number than one.
Backup operation can use parallelism but remember this is Not the parallelism driven by Optimizer in SQL Server its driven by number of disks involved from where backup has to read the data file and where backup writes the data file and amount of backup files created.
You cannot use MAXDOP hint while taking SQL Server backup
You cannot generate execution plan in SSMS for simple TSQL backup operation.
The parallelism driven by query optimizer in SQL Server is basically for operators involved ( actually its more complex but for sake of simplicity you can take this ) since backup operation does not involves any operator as such it cannot use parallelism driven by optimizer.
I wrote an article on Technet Wiki about Backup and parallelism where I used simple examples to explain parallelism during SQL Server backup. Following is the conclusion
If database files are on multiple disks backup operation would initiate on thread per device drive to read the data. In same way if restore is done on multiple drives/mount points backup operation would initiate one thread per drive/mount point
Even if you are dumping multiple copies of backup on same drive we would have one thread per backup file dumped.
The parallelism associated with backup is related to the stripes. Each stripe gets its own worker thread and that is really the only part of backup/restore that one should consider as parallel operations.
The max degree of parallelism has no affect on backup operation.
I got some expert opinion on this from Paul and Bob Dorr.
So what happens when a backup job is running? And also are there significant differences for the different versions? for example 2008,2012 and 2014 (not the licenses).
I would suggest you to read this blog.msdn article by Bob Dorr. Some important points he emphasized is
When a backup starts it creates a series of buffers, allocated from the memory outside the buffer pool. The target is commonly 4MB for each buffer resulting in approximately 4 to 8 buffers. Details about the calculation are located in: http://support.microsoft.com/kb/904804/en-us
The buffers are transitioned between the free and data queues. The reader pulls a free buffer, fills it with data and places it on the data queue. The writer(s) pull filled data buffers from the data queue, process the buffer and return it to the free list.
You get a writer per backup device, each retrieving from the data queue. So a a backup command with four(4) to disk specifications will have four writers and a reader. The reader uses async I/O so it can keep up with the writers.
You can enable trace flags 3213 and 3605, both are undocumented so please use it on test environment, and see what interesting message is dumped in SQL Server errorlog. Something Like below would appear
Memory limit: 249MB
BufferCount: 7
Sets Of Buffers: 1
MaxTransferSize: 1024 KB
Min MaxTransferSize: 64 KB
Total buffer space: 7 MB
Tabular data device count: 1
Fulltext data device count: 0
Filestream device count: 0
TXF device count: 0
Filesystem i/o alignment: 512
Media Buffer count: 7
Media Buffer size: 1024KB
I am not aware about any significant changes in backup code for various versions, such things are not documented. I only know about the enhancement introduced in SQL Server 2012 SP1 Cumulative Update 2, enable backup and restore from the Windows Azure Blob storage service from SQL Server using TSQL or SMO. Read here
