File Name Formats
Note:
Files appearing in the storage area are put there by various automated and manual processes. In some cases the user has the ability to modify the system generated file name. This section describes the system generated file names only.- Backup (Upgrade). This differs from the database backup and is a manual process.
- Backup (Database). This differs from the upgrade backup and can be manually or automatically generated.
- Checkup (Health Check). These are manually generated files.
- ISO. Manually uploaded and system managed.
- Logs. These are manually generated files.
- Servers (Configuration). These are manually generated files.
- <server name> or <hostname> is the server hostname from which the file is generated.
- <checkup type> is the upgrade health check type. These are EarlyUpgrade, PreUpgrade, or PostUpgrade.
- <checkup scope> specifies whether the health check was run on a server group or network element basis.
- <application name> is the name of the application.
- <group name> is the type of data stored in the backup file.
- <node type> specifies whether the backup was generated on an NOAMP or SOAM.
- <date_time_tz> is the date, time and time zone that a file was created. This format can vary from file to file. Some may use hyphens while others use underscores. Some files may not include the time zone. The data and time format is generally YYYYMMDD_HHMMSS.
- <task id> Task ID uniquely identifies an individual export task and can be correlated to an active task under .
- (AUTO | MAN) indicates whether the backup was automatically or manually generated.
- bz2 is a compressed archive file created by bzip2. This type of file must be uncompressed to access the content inside.
- gz is a compressed archive file created by gzip. This type of file must be uncompressed to access the content inside.
- log is a flat file type that can be read by a text reader.
- sh is a self-extracting archive commonly used in linux systems for scripting.
- tar is an archive container and must be unpacked to access the content inside.
- txt is a flat file type that can be read by a text reader.
Note:
The file types listed in Table 6-21 are among the most commonly seen in the file management storage area. The list, however, is not exhaustive and other file types may appear in the storage area.Table 6-21 File Name Formats
File Content Type | File Name and Description |
---|---|
Backup (Upgrade) |
Backup.<application>.<hostname>.FullRunEnv.<group name>.<date_time>.UPG.tar.bz2 Backup.<application>.<hostname>.FullDBParts.<group name>.<date_time>.UPG.tar.bz2 Note: In this case the upgrade backup created two files differentiated by run environment and database. Both are tar files separately compressed using bzip2. |
Backup (Database) |
backup/Backup.<application>.<hostname>.ProvisioningAndConfiguration.<group name>.<date_time>.(AUTO | MAN).tar.bz2 Note: A database backup can generate files using a default or custom file name. Additionally, the user can select compression or no compression. Available compression choices are bz2 or gz. Files generated using no compression are simple tar files. In this type of backup the user has the choice of Provisioning data, Configuration data, or both |
Checkup (Upgrade Health Check) |
<checkup type>_HealthCheck_<checkup scope>_<date_time>.txt A checkup generates a simple text file that can be viewed or downloaded. |
ISO File Image |
<name>.iso Note: ISO images that have been uploaded but not deployed present a different file name than ISO images that have been uploaded and deployed. For example, an uploaded DSR ISO image has a filename that starts with iso whereas a deployed DSR ISO image has a filename that starts with DSR. |
Logs |
ugwrap.log upgrade.log Note: Upgrade or system logs are different than security logs. Seculogs use the APDE framework to export security logs to the file management storage area. |
Servers (Configuration) |
TKLCConfigData.<hostname>.sh Note: Servers configuration data generally starts with the term TKLCConfigData. These are shell files. |
Note:
It is recommended that policies be developed to prevent overuse of the storage area. These might include a procedure to delete files after transferring them to an alternate location using the data export feature. See Remote Servers for details of the feature.