Before one upgrades, it's wise to perform a site backup ... which includes archive of code directory, a DB dump, and minimally and archive of moodledata/filedir/.
At the course level, one could turn on automated backups ... check backup preferences to assure those are set to backup all course content and I'd highly recommend saving course backups to a 'designated directory' which you would have to create manually and it's located outside of moodledata/filedir/
When you say you l'ost all content' ... were you using a third party theme? As a matter of practice, to avoid theme incompat, I use config.php file to force the use of boost as default theme. $CFG->theme='boost';
Did you get the 'white screen of death' or other? If you performed the upgrade as root user, all files/folders were tagged as belonging to that user (root). Ownerships/permissions on config.php file may have changed ... for moodle to function, config.php must allow global internet to be able to at least read the config.php flie.
Prior to upgrading, did you go to Site Admin -> Server -> Environment and update the component then set the moodle drop down version to destination version to see if there were any REDS or YELLOWS in environment check?
You can turn on debugging via config.php file by adding lines to config.php from section 7 of config-dist.php and then attempting to access your site via browser to see what Moodle might be complaining about.
Upgrades don't normally touch moodledata ... just moodle code + DB ... but as a standard practice on upgrades I now run command line cron just before the upgrade and immediately after a successful upgrade run purge all caches ... there are php scripts in code/admin/cli/ that will do those.
by Ken Task.
'SoS', Ken