Well you do have during installation.
You could easyly determine the actual size of the db and set the new db 10 times higher - jsut to be shure.
a daily cron job could check size of the sparse/actual size to determine if its nessesary to adjust the db setting.
that way the max size limit would be adjusted dynamically
seriisously dont you understand that a 80gig sparsefile has a major impact. only because the limit was set in 8.0 wont help - noone will check every single value of the settings for bad changes - even if they do they wont expect having a file there that size.
the minimum requirements of 90gig without data have to be documentated - in red big letters. its not trivial its a big deal.
btw a quick and dirty fix - really reserving that amount of space
and no you do not need to run db_recover prior rsync if you do a cold backup.
you backup the hole zimbra installation anyway.
heres a little note how we really backup (i hope most do that this way)
so what we do (i dont do it with rsync but our backup software but dont make much difference in the way todo it)
we backup hot - jsut to get most daty into the backup set - (always incremental of course)
then shutdown zimbra - backup everything - because of the incremental backup all we need to backup are recent changes and the database files
time for a hole shutdown backup 90 seconds atm - no need to run anything in advance - the backup is the exact mirror of the server with a shutdown zimbra
you can even restore such a backup easy on a different testing server, all its needed is one entry in /etc/hosts, prior installation of the same zimbra version just to get apt and some minor syschanges on to it -delete the new installation restore the cold backup - its running
(of course firewalling the smtp ports or it will send some mails hanging in the queues during backup time)