The Value of Having a Separate "Admin" Portal

Sharepoint portal deployments can be complicated to manage. They can include several customizations that make restores, upgrades, and day to day maintenance more difficult to perform.

Think about all of the data that is necessary to maintain in order to effectively manage Sharepoint.

Contact information
Invoices, subscription information
License compliance reports
Hardware (make, model, sn, RAID, tech support information)
IP addresses
Port numbers
SSL certficates
Users, passwords
Portal area security hierarchies
Group memberships
Service identities
IIS host headers
IIS app pool identities
Area/site templates
Unghosted pages
Branding, modifications to OWS.css, Menu.css, SPS.css, ..OWSPERS.css, OWSmac.css, OWSnocr.css, Paystub.css
Custom image files
Custom animation files (swf files)
Third party add-ons
Custom web parts (dwp files, assembly files, aspx files)
Custom javascript e.g. custom_owj.js
Data view, custom data sources to line of business databases
Custom security, site groups, ad groups, audiences, web part
Connected web parts
Dependency information
Datasources pointing to Sharepoint content db
Linked servers
Instruction documents
Backup and restore procedure
Support procedures
Log files
Code templates
Branding templates
Answers
Notes

One solution I have found to be very helpful is to deploy a separate Sharepoint portal with the sole purpose of maintaining administrative information. I like to keep it vanilla so that I can quickly restore it independently from the main portal(s). I find that it is really easy to lock down the portal when you are only going to allow administrators to access it.