SourceForge has essentially four data components that require the System Admininstrator to proactively back up in case of system failure. These components are:
As with most large and complex applications, the recommended method of backing up SourceForge involves shutting down the application. While it is possible to backup the application while it is up, the backup itself will not provide 100 percent data consistency. You should undertake one of these live backups only as a last resort and only after ensuring all the potential consequences are fully understood.
If, for whatever reason, a full, offline backup is not possible, you should do the following to ensure that as little data is being changed as possible. While these steps won't completely replicate the offline backup, they can mitigate most of the issues w/ doing a live backup. Again, we do NOT recommend this. Offline backups are your friend. Just schedule the downtime and take the hit.
For the CVS repositories, you should use whatever normal filesystem backup method your company prefers, much like the FILESTORAGE section above. For SVN repos, it is highly advised that you use the 'svn dump' action to export them to normal files and then backup those dump files. To do this, simply: svnadmin dump /svnroot/my_repo > /some/backup/path/my_repo.dmp
Please note that due the nature of SFEE, there are several interdependencies between these various data storage points. As such, you must take great care to ensure that all these components are backed up AT THE SAME TIME. You will NOT be able to use a database backed up yesterday morning with a filestorage from the night before.
Quieting the system
First, you'll want to turn off the web server so users can't get to the UI (assuming you are routing through Apache and not direct to JBOSS): service httpd stop
Second, on the SCM server, remove the execute bits on the SCM: chmod -x /usr/bin/{cvs,svn}. This will prevent anyone from executing 'cvs' or 'svn' for new checkins/checkouts/tags. Please note however, that it won't affect existing running processes. Either wait for them to finish, or kill them.
Finally, pause the search indexing engine: touch /usr/local/sourceforge/var/searchIndexes/LOCK_INDEXES
The database
The majority of SourceForge data is stored in the database. To back up the database, follow the recommended procedure from your db vendor. If you're using PostgreSQL, you can use the directions in the link below.
The file storage and search indices
Any documents uploaded to SourceForge, or attachments to an artifact or forum, as well as the search indices, are stored on the filesystem as normal system files. Please use whatever normal backup method you use to ensure filesystem restorability (tar, dd, cpio, Ghost, etc). You should backup the following directory and ALL its subdirectories: /usr/local/sourceforge/var
The SCM data
On the SCM box, you will also need to backup your SCM data. This data is contained in your companies various repositories which are located under: /cvsroot and /svnroot
Finishing
Once the backup is complete, remove the file: /usr/local/sourceforge/var/searchIndexes/LOCK_INDEXES
Turn on the execute permissions for the SCM binaries: chmod +x /usr/bin/{cvs,svn}
And restart Apache: service httpd restart