When you create a snapshot you aren't actually making a copy of the volume, only of the changes that you make to it from then on.

For example, suppose that you have a small filesystem with only ten files in it. Let's call then /01, /02, /03 and so on through /10. Normally if you were to overwrite file /01 then the new version of /01 would simply be written over top of the old one. (This is wildly oversimplified, because really there would be all sorts of journalling and the directory entry would be updated to point to a new inode containing the new data, but I'm going to skip all of that now.)

When you create a snapshot, that doesn't quite happen. A new version of file /01 is created, but the old copy is placed in a buffer just outside of the original volume. This process is called Copy On Write, which is why snapshots of cows are popular with people who like to make filesystem related puns. Different volume managers will put the original or modified blocks in the COW buffer, depending on whether they expect to throw away the snapshot or roll it back after, but the idea is still the same. I think that LVM2 makes copies of the old blocks so that it is easier to discard the snapshot data without having to merge it all.

When you try to access file /01 in the snapshot, LVM will check to see if the blocks associated with that file have been modified. Since they have been it will then read the old version of the file from the COW buffer. If you were reading file /02 instead then there would be no modified blocks and you would receive data direct from the real filesystem, just like you would if you were reading the non-snapshot version.

What's the point of all this? Well, it's to answer your two questions, only in reverse order:

2) Since the snapshot only needs to store blocks which have been changed, the Copy-On-Write buffer only needs to be large enough to hold those blocks. In our example the original filesystem held ten files, but since we only modified one then creating a snapshot buffer large enough to hold that one file would have been enough. The down side to this is that if we had tried to modify a second file then we would run out of space and the snapshot would stop working. I haven't tried this recently, but I think you would get an out of disk space error and the write would fail.

If your original filesystem is 2TB and that's all active database files which you expect to overwrite completely before the snapshot is removed, then yes you will want 2TB of snapshot, because that's how many files you want to change. If the majority of that will be read-only data and you only expect to change a few hundred megabytes of data then you can get away with a significantly smaller snapshot size. I would recommend allocating some multiple of your expected changes, such a a few hundred MB or even 1 GB in that case, just in case something unexpected happens.

It really comes down to you knowing what your system is doing and predicting what it is going to do with the snapshot volume. Nobody can tell you for sure what that is.

1) And, since reading the snapshot involves looking at both the original filesystem and the contents of the COW buffer, yes the snapshot does need to be in the same volume group. If it wasn't then you could wind up with very complicated situations like a snapshot being left online while the original volume in a different volume group was taken offline, and nobody wants to see how that's going to work out.

Also, even though you didn't ask, here's a third answer:

3) No, LVM snapshots make terrible backups because they don't actually make copies of anything.