Can someone explain what samples per buffer is?

Samples per buffer is the number of meaningful bytes of data held in the respective processing pool.

To big and each pool takes longer to process too small and they can overflow, loose data before processing.

Generally they should not affect an export unless you are doing some processing on export then the only real effect would be to increase the time to export by a few seconds.

When recording too big and it will affect the latency especially if you are monitoring the input via DAW processing.  i.e. Playing you guitar through GR3/4 and hearing the effects as you play. Or using soft-synths played from a controller.

Playing back to small will reduce the amount of processing that can occur before dropouts happen.

Does that make it any clearer?

i guess you mean sample rate in exporting, does it lose quality at 44.1 compared to 48/88.2/96 etc? yes. it'd dithered down using some kind of algorithm, and very well done, but yes ultimately you lose 'samples' ie frequencies. you'd have to have a good ear, mind, with todays better resamplers such as the POW-R ones included with SOnar... note that dvd-a is at a higher sample rate than cd audio, for example...
ps this is different to the number of samples kept in a buffer, which is designed to keep audio playback constant...

Can someone explain what samples per buffer is and how it can affect my playback, recording and exportation?

 
Let's try another explanation;
 
Audio is streamed in chunks. Those chunks are held by buffers. A typical chunk contains from 32 to 256 samples (instantaneous measurements of the signal amplitude) or more. In a hypothetical 48kHz system (48000 samples per second), a buffer of 64 samples delivers 1.5ms (milliseconds) of music. Small buffers give a faster response to control changes in your DAW and a shorter delay when echoing input back to the output for monitoring with effects added by the DAW, but small buffers have to be re-filled at a very high rate, putting a high load on the CPU (imagine a bucket brigade trying to put out a fire by passing teaspoons of water).
 
If the CPU can't keep up with the demand, and one of those "teaspoons" comes up empty because it had to be passed before it could be filled, you get a dropout. A single empty buffer will give you one pop or click. A series of them will sound like static.
 
All of this only matters for real-time streaming of audio (which could include effects processing and multi-track summing, adding to the work the CPU has to do before it can pass  a chunk of audio samples to the buffer).
 
Exporting is not a real-time process, it's just "offline" number-crunching and file-writing. The audio interface, sample clock and sample bufffers are not involved. The audio can be processed in much larger chunks and in ways that are more CPU-efficient, so export is actually faster than real-time streaming. So long as all of the plug-ins in the project are compatible with the higher non-realtime processing rate (mosts are, but many disk-streaming synths and some effects plug-ins are not) There is no effect on audio quality of the finished export.
 
Hope that helps clear some things up.

Thanks for the intial thought Wookie, thanks for the further clarification brundlefly and thanks for even more info Guitarhacker. Know i understand. I was just afraid to change it before because i though it would affect my recording quality, and exporting too. Thanks a hellload!

That's an imaginative analogy, brundlefly! A bucket brigade of teaspoons - how Lewis Carrol.

Thanks, Bit. It just came to me suddenly. I thought that might elicit a smile or two. 

The next question, though, will probably be "what's a 'bucket brigade'?".

That occured to me also. Pretty soon no one is going to remember why we call it "dialing" the telephone, either.