Back up Files data

Overview

Files stores data in both the database, and a file system. This adds some complication in keeping the application available to users while backing up data.

To use administrative commands, use wsadmin.sh.

Files stores a large amount of data. If it were only stored in the database, maintenance and backups would be complex and costly. To prevent this, Files stores file metadata in the database, and stores the bulk of file data in binary files in a directory on a file system. You specify the directory during IBM Connections installation, and we can find it at any time in files-config.xml, in the element...

file.storage.rootDirectory

...which contains either the path itself, or a WAS variable whose value is the path. If it contains a variable, we can find the path by opening the WAS console, clicking...

Environment | WebSphere Variables

For example, if the element's value is...

${FILES_CONTENT_DIR}

...find...

FILES_CONTENT_DIR

File data is stored in unique directories below...

storage_root_directory/files

Each file's data is stored in a sub-directory below /files, generated from the file's randomly generated UUID. Part of the UUID is used to create a directory with a number between 0 and 127. Another part is used to create another directory below that, with another number between 0 and 127, and the UUID itself is located in that directory. For example:

storage_root_directory/files/18/113/file_UUID

Files are only written once, so their identities are clear if one is missing during a restore.

The simplest way to maintain consistency is to perform "off-line" backups, making the application inaccessible and then backing up both locations. But often you will want to perform "on-line" backups, keeping the application accessible. During an on-line backup, users can continue to add and delete content from the application.

During on-line backups of Files, back up the database before the file system. The database enforces transactional integrity between the two locations. If we start the file system backup first, files added between the time the file system backup starts and the database backup later completes will be missing from the file system on restoration. Backing up the database first ensures that you capture all new files during backup.

Stop file deletion tasks from running during on-line backup. When a user deletes a file it is removed from the user interface, but the application actually adds it to a queue of files that must be deleted from the file system. This task runs regularly to delete the first item from the queue. Alternatively, we can increase the time files can sit in the queue before they are deleted, by adjusting the value in the property...

scheduledTasks.FileActuallyDelete.args.softDeleteMinimumPendingTimeInMins

...in files-config.xml. This could give you enough time to run incremental backups and verify the archive is never missing data.

Perform an on-line backup of Files

1. Start the Files Jython script interpreter
   ./wsadmin.sh -lang Jython
   execfile("filesAdmin.py")

2. Stop the task that deletes files from the queue:
   FilesScheduler.pauseSchedulingTask("FileActuallyDelete")

3. Back up the database according to the database documentation.

4. Back up the file system. For small deployments we can just zip the system, or for large deployments we can use a tool like Tivoli Storage Manager.

5. Start the task that deletes files from the queue:
   FilesScheduler.resumeSchedulingTask("FileActuallyDelete")

What to do next

• Checking Files data integrity
  
• Synchronize Files data with Communities data
  

Parent topic:
Administer Files

Related:
Maintain application databases
Start the wsadmin client
Find the location of a stored file
Change Files configuration property values
Files administrative commands