In addition to the great information by @BenVoigt, allow me to make some additions:
A breakpoint is set by the debugger by replacing a machine code value (an instruction or part of an instruction) in the process being debugged with a particular trap instruction at the location in code that corresponds to the desired (source) line to break at. This particular trap instruction is meant for use as a breakpoint — the debugger knows this and so does the operating system.
When the process/thread being debugged hits the trap instruction, that triggers the process @Ben is describing, which includes the half of a context swap that suspends the currently running thread (which includes saving its CPU state to memory) for potential later resumption. Since this trap is a breakpoint trap, the operating system keeps the process being debugged suspended using perhaps a mechanism @Ben describes, and notifies and eventually resumes the debugger.
The debugger uses system calls, then, to access the saved state of the suspended process/thread being debugged.
To execute (resume) the line of code that broke (which now has the particular trap instruction), the debugger will restore the original machine code value it overwrote with the breakpoint trap instruction, possibly set another trap somewhere else (e.g. if single stepping, or the user makes new breakpoints), and mark the process/thread as runnable, perhaps using a mechanism as @Ben describes.
Actual details can be more complicated, in that keeping a long running breakpoint that is hit means doing something like swapping out the breakpoint trap for real code so that line can run, and then swapping the breakpoint back in again...
Aren't those register being used by other OS processes constantly? how do they not get overwritten?
As @Ben describes, using the already existing thread suspend/resume feature (the context switching/swapping of multitasking) that allows processors to be shared by multiple processes/threads using time slicing.
Is it only a snapshot of the content and not live data?
It is both. Since the thread that hit the breakpoint is suspended, it a snapshot of the live data (CPU registers, etc..) at the time of suspension, and the authoritative master of the CPU register values to restore into the processor should the thread be resumed. If you use the debugger's user interface to read and/or change the CPU registers (of the process being debugged) it will read and/or change this snapshot/master using system calls.