Our FME Server fsconfig backup file is 15Gb. It is a 2015 server that we plan to upgrade to version 2017 and then clean up the legacy workspaces that we inherited from another team.
But with a back up of 15Gb I expect problems when I read that other users on the forum had problems with a 3Gb backup file.
What is the easiest way of determining what is contributing to the large backup file size so we can clean the biggest offending workspaces etc.
Thanks in advance,
Annette
Before doing the backup, the first thing I'd do is to trim all the old log files. You can activate the FME Server cleanup task (if it's not already enabled) to delete all log files older than a certain time.
Before doing the backup, the first thing I'd do is to trim all the old log files. You can activate the FME Server cleanup task (if it's not already enabled) to delete all log files older than a certain time.
You may also want to check that you don't have any temporary data lying about in the shared resouces.
You may also want to check that you don't have any temporary data lying about in the shared resouces.
This link to the 2015.1 documentation lists everything that's included in a backup. I'd check all of those folders to see what you've got in there that'd cause the back up file to be so big.
I'll chime in here...
It might be too late if you've moved on but many times the backup file (.fsconfig) is so big is because of data files that were uploaded with workspaces. An example, would be File GDB.
File Geodatabase comes to the fore front with my experiences as they can easily take grow in size and may use up lots of space and before long you'll have big backup files (.fsconfig). This isn't a bad thing but it can present problems when restoring as you have noted. As David_R suggests, if logs are not cleaned up these could be a factor but I think it will be related to data in the workspace repositories or data that was created OR stored in the Shared Resources folder (ex. Data folder).
Be aware, when attempting to restore this 15GB file it will need 2x the space on the new system.
An alternative approach, but not documented, is to manually backup large files and manually restoring them after the FME Server restore is completed. I've had to do this a few times with customers who were having problems restoring to a system that didn't have enough space. If diskspace is not an issue I recommend first giving the documented backup and restore process a go. Only consider the following alternative if you encounter issues with the size of the backup and please feel free to contact Safe Support for guidance on this approach if you are uncomfortable with the steps or the explanation here.
The suggestion is to determine the location of any large files or folders within the Repositories or the Shared Resources folder of FME Server. This is done at the OS level. On Windows the default location for the Repositories and Shared Resources is C:\\ProgramData\\Safe Software\\FME Server\\. The subfolders repositories and resources are the possible locations for the large files I'm referring to. A tool like TreeView for Windows for example can help you locate such files & folders very quickly - there are many other tools. Linux OS users can do this at the command line with little trouble.
Once the large files & folders are identified:
1) Note the location within the shared resources folder,
2) Move the file/folder, that is physically move it out of this location (backup manually to a file server for example) and then do the FME Server backup. (confirm that the fsconfig file is now smaller).
The backup should be smaller and more manageable to work with and copy to other systems where you might be restoring FME Server to.
3) Now run the FME Server Restore as normal, then simply copy the data files back to the correct location on the new system (recalling the 'noted' locations from step 1).
It is also worth mentioning, the .fsconfig file is an archive... a zip file, you can look inside it and see what is in there.
Before doing the backup, the first thing I'd do is to trim all the old log files. You can activate the FME Server cleanup task (if it's not already enabled) to delete all log files older than a certain time.
I'll chime in here...
It might be too late if you've moved on but many times the backup file (.fsconfig) is so big is because of data files that were uploaded with workspaces. An example, would be File GDB.
File Geodatabase comes to the fore front with my experiences as they can easily take grow in size and may use up lots of space and before long you'll have big backup files (.fsconfig). This isn't a bad thing but it can present problems when restoring as you have noted. As David_R suggests, if logs are not cleaned up these could be a factor but I think it will be related to data in the workspace repositories or data that was created OR stored in the Shared Resources folder (ex. Data folder).
Be aware, when attempting to restore this 15GB file it will need 2x the space on the new system.
An alternative approach, but not documented, is to manually backup large files and manually restoring them after the FME Server restore is completed. I've had to do this a few times with customers who were having problems restoring to a system that didn't have enough space. If diskspace is not an issue I recommend first giving the documented backup and restore process a go. Only consider the following alternative if you encounter issues with the size of the backup and please feel free to contact Safe Support for guidance on this approach if you are uncomfortable with the steps or the explanation here.
The suggestion is to determine the location of any large files or folders within the Repositories or the Shared Resources folder of FME Server. This is done at the OS level. On Windows the default location for the Repositories and Shared Resources is C:\\ProgramData\\Safe Software\\FME Server\\. The subfolders repositories and resources are the possible locations for the large files I'm referring to. A tool like TreeView for Windows for example can help you locate such files & folders very quickly - there are many other tools. Linux OS users can do this at the command line with little trouble.
Once the large files & folders are identified:
1) Note the location within the shared resources folder,
2) Move the file/folder, that is physically move it out of this location (backup manually to a file server for example) and then do the FME Server backup. (confirm that the fsconfig file is now smaller).
The backup should be smaller and more manageable to work with and copy to other systems where you might be restoring FME Server to.
3) Now run the FME Server Restore as normal, then simply copy the data files back to the correct location on the new system (recalling the 'noted' locations from step 1).
It is also worth mentioning, the .fsconfig file is an archive... a zip file, you can look inside it and see what is in there.
One mistake I made was to move the folder in the repository without deleting it first within the FME Server front end. When I did this the backup wouldn't complete. It was looking for the workbench and the uploaded xml files. I restored, deleted within the web front end and ran the backup. Now we are down to 100Mb. I will test the back up tomorrow.
Thanks again for the detailed answer. Hope you are keeping well :)