Can files be deleted from the "backup" directory in order to save filesystem space

Answer

Yes, you can delete some of the files in the backup directory. The product does not have tools which handle this, so you must manually delete specific files. You need to proceed with care, because there are rules which dictate which files you can, and cannot, delete. Continue reading this article for information regarding which files can be safely deleted.

To be clear, this article refers specifically to the .pak files in the following directory:

install_root/properties/version/nif/backup

The advice in this article only pertains to that directory, and only the .pak files for WebSphere Application Server whose name includes "-WAS-", and CIP slip install backup files whose name "CIP ID + WebSphere Application Server component name" naming convention. (These file names are explained in detail further below.)

Note that the maintenance pack files you use to update the product (those which you download from IBM) also have ".pak" file extensions, and have very similar file names as to what is stored in the backup directory. The maintenance pack files which you obtain from IBM are different than the files in the "backup" directory. Those maintenance pack files from IBM can be deleted once the maintenance pack is installed on the product.

Similarly, CIP slip installs also create backup files which are placed in the backup directory. (A "slip install" occurs when a CIP applies maintenance packs to an existing installation of WebSphere Application Server.) The backup files for CIP slip installs follow a convention of "CIP ID + WebSphere Application Server component name". The CIP ID is chosen by the person who created the CIP, and usually has a name such as "com.company.websphere_7.0.0.0". WebSphere Application Server component names vary, and have names such as "ejbdeploy" or "primary". So, the CIP slip install file names in the backup directory have names such as "com.company.websphere_7.0.0.0primary.pak".

Limitations of deleting files
Deleting certain backup files is supported. But, as a consequence of deleting those files, you cannot uninstall the particular fix pack or CIP associated with the deleted files. You cannot "transplant" a set of backup files from one WebSphere Application Server instance to another WebSphere Application Server instance in case you need to un-delete the backup files. (Copying backup .pak files from one instance of WebSphere Application Server to another could potentially irreparably damage the product.)

The same consequence applies to WebSphere Application Server V7.0 nodes managed using the Centralized Install Manager (CIM) feature: If backup files are deleted from managed nodes, uninstallation of those particular fix packs will fail when using the CIM feature from the deployment manager.

Guidelines for what can, and cannot, be deleted

These general guidelines describe which .pak files can and cannot be deleted from the following directory:

install_root/properties/version/nif/backup

You must not delete:

• The .pak files which were originally installed with the product
  
  
• Interim fix .pak files
  
  
• The most recently installed fix pack for a "stack". (In other words, do not delete the most recent application server and SDK fix pack backup files.)
  
  
• The "EP" (enablement pack) files. You must be careful, because the EP packages (which should not be removed) have similar names as other files which can be deleted.
  
  
• Do not delete the whole "backup" directory!

You can delete:

• Fix pack backup files (except the most recent fix pack for WebSphere Application Server or the SDK)
  
  
• If you delete a certain fix pack for WebSphere Application Server or the SDK, then all the respective fix packs before that fix pack must also be deleted.
  
  
• You can also delete the files from the properties/version/nif/recovered directory. These files are only needed when a previous fix installation or uninstallation has failed.
  
  
• CIP slip install backup files

Additional details and examples:
A single fix pack might be represented by 1 or more files in the "backup" directory. When you want to delete a fix pack from the backup directory, you should delete the whole group of files associated with the fix pack, not just 1 or 2 of that fix pack's files.

A group of fix pack files are identified by strings ending with "FP00000*" or "FP610*". For example, the fix pack files associated with Fix Pack 9 will have names that either contain "FP0000009" or "FP6109". Fix Pack 23 will have names that either contain "FP0000023" or "FP61023". The files which fit these characteristics can be safely deleted.

You should assume that other files, which do not fit those characteristics, are not safe to delete. For example, a file named "6.1.0.19-WAS-IFPK12345.pak" is not safe to delete. That file does have "-WAS-" in it, but it does not reference "FP610*" or "FP00000*". That is not a fix pack. Another file, such as "6.1.0-WS-WAS-LinuxX32-EP0000015.pak", is not safe to delete. Notice that the file contains "EP" (Enablement Pack), not "FP". (This is specifically pointed out because it is a subtle detail, but it is an important one.) A file such as "was.primary.pak" is also not safe to delete.

You can also delete the files whose name follows "CIP ID + WebSphere Application Server component name" naming convention. These are the backup files for a CIP slip install. Typically, those file names look like "com.company.websphere_7.0.0.0ejbdeploy.pak" or "com.company.websphere_7.0.0.0primary.pak".

Consider the following example. You want to delete everything related to "Fix Pack 15". In this case, you want to delete both the Application Server fix pack and the SDK fix pack. So, list out all the files in the "backup" directory which contain "*15*". Here is an example list, which is split into different sections to explain them:

1. 6.1.0-WS-WASSDK-LinuxX32-FP0000015.pak
2. sdk.FP61015.pak
   
   
3. 6.1.0-WS-WAS-LinuxX32-FP0000015.pak
4. was.embed.common.FP61015.pak
5. was.embed.FP61015.pak
6. was.itlm.nd.FP61015.pak
7. was.license.FP61015.pak
8. was.ndonly.common.FP61015.pak
9. was.ndonly.FP61015.pak
10. was.server.common.FP61015.pak
11. was.server.FP61015.pak
    
    
12. 6.1.0-WS-WAS-LinuxX32-EP0000015.pak
13. 6.1.0.19-WAS-IFPK12315.pak

The first group of files (1 and 2) is Java SDK Fix Pack 15. You can delete those 2 files safely.

The next group of 9 files (3 to 11) is the Application Server Fix Pack 15. You can delete all 9 of those files safely.

The last 2 files (12 and 13) require further explanation:

• The 6.1.0-WS-WAS-LinuxX32-EP0000015.pak file is an Enablement Pack, because it has "EP" in the filename. Do not delete this file. (Be careful, because this file name looks very similar to another file which you can safely delete.)
  
  
• The 6.1.0.19-WAS-IFPK12315.pak file is an interim fix which was installed on this product, which happened to have the number "15" in it. That file is not safe to delete. Interim fix are not part of the list of things that are safe to delete.

As another example, consider a different application server installation instance. This application server has had many fix packs installed on it. Here is a list of what is installed on this example application server:

• Fix Pack 9 for the Application Server
• Fix Pack 11 for the Application Server
• Fix Pack 13 for the Application Server
• Fix Pack 15 for the SDK
• Fix Pack 17 for the Application Server
• Fix Pack 17 for the SDK
• Fix Pack 19 for the Application Server
• Fix Pack 21 for the Application Server

Let us examine which files are safe to delete. You can safely delete the sets of backup files for all these fix packs:

• Fix Pack 9 for the Application Server
• Fix Pack 11 for the Application Server
• Fix Pack 13 for the Application Server
• Fix Pack 15 for the SDK
• Fix Pack 17 for the Application Server
• Fix Pack 19 for the Application Server

Fix Pack 21 for the Application Server is not safe to delete, because it is the "latest" fix pack installed for the Application Server. Also, Fix Pack 17 for the SDK is not safe to delete, because it is the "latest" fix pack installed for the SDK. The SDK and Application Server fix packs are considered to be on 2 different "stacks", and the latest fix pack for each "stack" must be preserved.

It is also acceptable to chose not to delete Fix Pack 17 for the Application Server. That way, it is possible to fall back onto the 2 most recent Application Server fix packs if needed (Fix Pack 19 and Fix Pack 17).

If Fix Pack 17 for the Application Server is deleted, then every Application Server fix pack before Fix Pack 17 must also be deleted. Following the example above, it is not acceptable to delete Application Server Fix Pack 17, but then keep Application Server Fix Pack 13 or 11 or 9. All 3 of those fix packs for the Application Server must be deleted.

If Fix Pack 17 for the Application Server is deleted, then Fix Pack 15 for the SDK does not need to be deleted. The act of deleting Application Server Fix Pack 17 only requires you to delete the other Application Server fix packs, which are in the same "stack".


Alternative solution: Move the files instead of deleting them
Ideally, you should not completely delete the files. Instead, you should move the files to a separate filesystem, or perhaps write them to external media (such as a DVD). For the sake of readability, this article discusses "deleting" the files, but "deleting a file" can be interpreted as "moving the file to a separate location".

By moving the files to a separate location instead of deleting them, the files are preserved, and therefore they can be restored in case they are needed someday. Note that, as mentioned earlier, you cannot use the backup files from one instance of the product on another instance of the product. So, if you choose to preserve the backup files, you must preserve a set of files for each individual copy of the product installed in the environment.