Besides just a backup, are you looking for High Availability, Disaster Recovery, or both? The Portal repository folders (e.g., Portal directories) referred to earlier are certainly one part of it, but if you're using a Managed Database for Portal then you'll need to consider that too. There are so many ways to set up and configure Portal in order to have a primary (active) and secondary (standby) Portal site. How about these approaches?
High Availability
Store the Portal directories on a Storage Area Network (SAN) or some Direct Attached Storage (DAS) which uses RAID technology, then either cluster two servers together where the SAN or DAS drive is attached to both as a Logical Unit Number (LUN) or don't cluster them and instead map as lettered drive to both servers. The Portal for ArcGIS software would be installed on both machines. Since the Portal directories exist on a redundant storage array, your chances of data loss are minimized considerably. Your single point of failure is the SAN or DAS, but that's unlikely to fail. If not using clustered servers, then you have a higher likelihood for downtime if one node fails even if using load balancing technology in front of your servers. As far as the Managed Database goes, it should be backed up nightly using RDBMS tools and those backups should be written somewhere safe like tape storage. Ideally, you'd be using something like Oracle RAC (although technically not 'supported' by Esri). This solution can be somewhat expensive.
Disaster Recovery
Use something like XCOPY or RoboCopy to periodically copy the new and changed files from one server to another in a one-way manner. If your primary Portal server goes down, you can point everyone to your secondary Portal server in the interim and then RoboCopy or XCOPY back once the primary comes back up. Another option is to use hardware-based replication from one site to another and to use RDBMS replication from one site to another for the Managed Database. However, this solution is very expensive.
The ultimate solution might be a combination of both DR and HA solutions above, with whatever modifications make sense for your organization. On the other hand, the quick and dirty (and cheaper) solution would be to XCOPY or RoboCopy your new and changed files from the Portal directories on a periodic basis from one server to another. Depending on your database licensing, you could use a shared database between your hot and cold sites or use RDBMS replication from one to the other in order to maintain two separate, yet in-sync databases.
The above solutions are meant to serve as high-level guidance. They are not prescriptions for exactly what you should do, but merely some ideas to consider based on your requirements.
