Each snapshot you create make reads and writes slower, as qemu has to
lookup data through the entire chain.
When we take a snapshot, we create a new file (or block device) and make
the new file the active layer of the chain.
For example, assuming you have a base image in raw format:
image-1.raw (top)
After taking a snapshot, you have:
image-1.raw <- image-2.qcow2 (top)
Now when qemu need to read data from the image, it will try to get the data from
the top layer (image-2), if it does not exists it will try the backing file (image-1).
Same when writing data, if qemu need to write small amount of data, it may need
to get entire sector from a another layer in the chain and copy it to the top layer.
So after a month of backups, will have 30 layer in the chain. I don't know how
much slower it will be, I never measured this.
For backups, I think you like to have something like a daily backup for the last week,
a weekly backup for the last month, and so on.
For daily backup of the last week you can take a snapshot every day, and delete
the 7th snapshot every day. Then backup the snapshot bellow the active layer.
You can download the snapshot using the SDK, see the download_snapshot
example (requires 4.2). All this can be done while the vm is running.
On your backup, you will have a snapshot per day. You can keep all snapshot
or merge old snapshot using qemu-img commit.
It is also should be possible to reconstruct an image on storage from your backup
by uploading the the snapshots back to storage - but it is tricky to get right.
I think the best option for users is to get some 3rd party solution based on
the oVirt SDK.
Adding qemu-block mailing list, they can probably add more info on how much
you pay for large chain of images, and have more ideas about backing up
qcow2 chains.