Depends if its a VM or not.
If its a VM, the simplest roll back is to get your infrastructure guys to take a snapshot of the entire VM before you start. Then rollback is just restoring that (depends how friendly your infrastructure guys are)
If not then you can backup the DB. Don't forget to backup the encryption keys (make a note of the password you use for this) and make a note of the settings/user accounts used in the SSRS-PBI config tool. You'll need the encryption keys to access some of the DB content, important stuff like connectionstrings and stored usernames and passwords. You should this anyway as part of any DR plan.
If like me you're really paranoid, we keep a copy of all our reports on disk anyway as we export everything out regularly. There are PowerShell scripts kicking around that do this. I've never had to import them wholesale, just push an odd one back in where some change to a report needs to be rolled back.
Make sure you have the old Installer available so you can run that to repair/re-install if the upgrade goes badly. I think the new installer will enable an "un-install" that should set things back to the way they were. You may have to uninstall the new version and then run repair using the old version.
All your content is in the DB anyway. So once you have a working environment you can restore the DB and encryption keys and get back to where you were.
Of course if you want to try it first you could get them to spin up a new VM, Install Oct17 onto that, restore the DB and Encryption keys to get you a working replica environment and then run the upgrade/update on that first.
It all depends how much wokr you want to do. We have VM snapshots that we can backtrack into so its really low risk to just run this stuff for us.
I notice in my installation directory I have a PBIRS folder (the current deployed server) and a PBIRS.OLD folder which I assume is the Oct17 version of the codebase.