Idea: git as part of upgrade backup procedure.

[crythias]

Nothing is a replacement for a good reliable, restorable, tested backup. This topic is intended to suggest redundancy of recoverability with (hopefully) minimal pain. Once git is installed, you now also have the ability to keep log history of changes to key files, such as Config.pm and .dtls in your own themes.

http://cworth.org/hgbook-git/tour/
http://help.github.com/git-cheat-sheets/

backup your database and otrs folder. You have been warned.
So, basically, if I understand it correctly, if you have git installed, you'd go to /opt/otrs and type
git init
http://www.kernel.org/pub/software/scm/ ... -init.html
which creates the git backup structure
then you'd add all the files in otrs with
git add .
and then something like:
git commit -m "Pre backup to 3.0.5"

and now you can (ahem) safely overwrite your otrs directory with the new source.
If you want to revert, you should be able to type
git reset
http://www.kernel.org/pub/software/scm/ ... reset.html
and get everything back. Be aware that changes to database schema will not be reversed.

You should try stuff like this on some sample folders and understand the implications of all the commands, especially git reset. If you don't understand this topic, or it doesn't make any sense to you, don't try it on your production instance.

---
Edit to add: (after a long time, and some personal usage with git 5/17/12)
It may be better to use branches than reset.
For instance, something like:
git add .
git commit -m "Current status mm-dd-yyyy"
git branch upgrade3-1-x
git checkout upgrade3-1-x
update otrs according to otrs instructions
git add .
git commit -m "Upgraded mm-dd-yyyy"

Then every time you make changes to anything, just
git add .
git commit -m "I did this thing. It was to address this issue."

optionally, git push to some other repository as a backup.

As before, you may want to review git and understand what it does before going all wild on your production system. *most* of the time, git is non-destructive, but you should play with git (it's free!) to understand how it works, and how you can avoid creating lots of individual backup configuration files. Just remember: commit early, commit often, and you can have greater piece of mind when you start making changes to OTRS. Also, make good log messages so people understand the history of the commits. Nonetheless, backup backup backup.