Online Backup in client-server mode

Hello,

we have issue with online-backup when using client-server mode.

It seems, that it is working the following way.
When we run the backup, server is creating tmp file for whole database and then copying it to the target location.
So it takes twice as long and consumes twice storage space.

Can it be improved? In my opinion the server proces should handle whole backup proces and do it as efficiently as the embedded mode does it.

Actually in client-server mode you have two options for online backup:

1. If your specify a File instance as the target parameter then a temporary file is created on the server and then, when ready, downloaded to the client. This is useful when the client and the server are not on the same machine, and the temporary file is essential to minimize the time that the database is locked for backup (e.g. when the connection between the client and the server is slow).
2. If you specify a String instance as the target parameter then it is interpreted as the path on the server machine to which to write the backup file and no temporary file should be created.

See also the ObjectDB manual.

Hello,

Thank You, I missed that part in the ObjectDB manual.
Indeed we've had the File as the parameter.

But now it seems, that the Absolute path on Linux/MacOS is not working.

When I enter the path /tmp/odb_backup it is still creating backup relative to the ObjectDB home directory

You are right - that is also the behaviour as described in the manual: "When a string is specified as a value for the target parameter it represents a path relative to the ObjectDB home directory, and in client-server mode, relative to the ObjectDB home directory on the server side."

As a workaround, consider using a symlink (symbolic link) under the ObjectDB home directory referring to your preferred external directory,

Hello,

workaround is working. But can you support absolute addresses please? How hard that can be?

Indeed, it is easy to implement, but we have to consider the benefit (apparently, making it a bit easier for one user that currently needs this feature but can also use a workable workaround) against the risks (things may start work differently or break for other users).

We should probably treat any string that starts with "/" as absolute, but doing that now may change the behaviour for other users. Therefore, it may be better to postpone this change until the next API change. Other solutions (like adding a special prefix for absolute paths) are not very natural so adding them and then supporting them forever (including with tests, documentation, etc.) seems unjustified in this case.

That said, there are future plans to extend the backup API and then this issue should be addressed.