Be careful! A "shapefile" is a specific set of files with a published set of formats. It is not possible to create a shapefile "in" a file geodatabase. Creating a feature class in a file geodatabase creates a new table within the FGDB, which is allocated the next available "slot" in the file geodatabase naming scheme. When you import a shapefile into a file geodatabase, you are creating a new table with a similar schema, but the data is no longer in shapefile format.
If you physically place the shapefile set member files in the ".gdb" parent folder, you will render these files invisible to Desktop or Server, because a ".gdb"-suffixed folder has a special meaning to the data discovery subroutines.
The "system catalog" approach used in file geodatabases (to store the file names and column properties in tables of the geodatabase schema itself) is an old, old trick, that predates the "INFO" days of Arc/Info. It is also used by PostgreSQL; you can see this if you ever wander into a tablespace directory owned by the 'postgres' user. Oracle and SQL Server do the same, but the virtual tables are hidden in the black-box implementation of "tablespaces" and "filegroups".
In order to archive a file geodatabase you must capture ALL of the files under the ".gdb" directory (including the directory itself, but with the possible exception of the ".lock" files). Creating a new table will create new files and modify others. Adding rows to a table will modify the data file and any index files. You can guess which "slot" is issued to which table by the growth pattern, but it is not in any way "safe" to archive only the data files in the slot without the framework that supports the content.
I should probably also mention that file geodatabase is recommended for local, not network-shared, use. Something about the perfectly reasonable file access pattern used in the ArcObjects and FIle Geodatabase API makes for a significant (~2x) I/O performance penalty over a network.
- V