Open Source Document Management System | OpenKM

Hi.

I am checking a backup strategy for openkm. I am having trouble with very big file on repository dabase filesystem. My repository size is about 5Gb and I have found most of this data stored exclusively on one file of 5Gb size. ¿is this normal? I though filesystemdb would spread throu files.
Obviously such size on a faile is never desirable for filsystem or transfers for a backup.

Thanks.

It\'s like you\'ve got and oracle database for example, you could get files so big, I think this might not be a problem.

The backup strategy it\'ll depends if you use external database or not. If you\'ve community and you\'ve not changed it confuration, a good backup strategy is to save all jboss installation folder ( with jboss stopped ), you can do for example sundays night, that\'s the most easy way to do and goes fine for major installations.

I am running a default installation. I don\'t have to much knowledge how a filesystem based database works, but, most of the data on the repository (5Gb) was added throught the import tool.. something related?. I have noticed any other data added to oder subfolders does not increase this big file and creates new ones instead. It is a problem for me because I run backups to other location through WAN, so incrementals are unusable with such a big file.

About backup strategy,my bet would be for a hot backup not having to stop jboss, because I\'ve got users spread through the world with different time zones, so it is not easy to stop jboss. Are database files always opened? On a daily backup cicle, I could maybe face aleatory missing opened files... Definetly, the good alternate would be to generate a daily local copy of the repository and backup this copy as desired.

If you use a delta copy utility like Rsync the backup process can take vary little time. But if you can\'t stop JBoss for a few minutes then you should use a database as backend, for example.