keyword: backupstrategy or "nobody needs backup, everyone needs restore".

i cannot give you an indepth introduction into backupstrategies.
but short:

you have distribution dependend data and local data(you may distinguish further).
if you want to restore the distribution dependend data you restore it from the distribution server. just reinstall.
you can't however restore the local data from the distribution server. so that needs extra backup.

if you make an upgrade and don't like it: you do a roll back to the old version and reinstall the old software. you need no backup for that.

that of course only works if you have local and distribution dependend data strictly separate. otherwise you can't do the rollback.

edit: 2 examples:
1) take an adressbook application. now you have the app and all your adresses. if you have them separate you update or reinstall the aplication anytime and have all your adresses still in place. if you don't like the new version you just install the old version and you still have all the adresses.
if this is not possible for some reason(e.g. format of how adresses stored changed) the installer/updater should /ask/ you what to do and never ever just discard your adresses. further an update should be able to manage to import the old adresses(that by all means not deleting it without asking).
2)non distribution applications:
addon debs just need to be packed in a way to install to /usr/local instead of the main distribution. that way you keep a) the distribution sane and b) dont delete any addon software with an update. you /can/ offer addon "shops" that provide addon packages that are independend of the distribution.(the addon might work or not but this is no concern of the distribution.) and if an upgrade of the distribution breaks an addon it's up to you to handle that. but it's only the addon that is broken and not the dist and can be updated once there is a new version.

another note to addons: the package management works on a policy set by the maintainer of a package. so the maintainer can choose to hold back an update of an addon untill the distupgrade happens and have the update installed with the upgrade. on the other hand he can choose a policy to deinstall the addon if dependencies no longer met(the software wouldn't work anymore with an upgrade) and the addon would get deinstalled. in the latter case still the userdata(that is the adresses in the example) stay on the system as long as the user doesn't explicitly say he wants to have the whole thing purged, that means with a new version of the addon the adresses are there again even though the app was temporarily deinstalled for it was broken.
this and much more is what the packagemanagement is capable of.


[no this is not easy but this is what packaging and creating an distribution is all about.]