Yes. This is the old backup system (6.2 and prior), which writes to the system keyspace.
In 6.3, there is a new role “BackupWorker” in the cluster, which pulls mutations from transaction logs and upload them to blob (i.e., pushing mutations out). Note BackupWorkers are FDB internal processes. In contrast, backup agents are external, and only talk to Proxies to read data out.
Backup agents are just clients, they talk to storage servers for reads like any other.
In 6.3, there is a new role “BackupWorker” in the cluster, which pulls mutations from transaction logs and upload them to blob (i.e., pushing mutations out). Note BackupWorkers are FDB internal processes. In contrast, backup agents are external, and only talk to Proxies to read data out.
Seems a solution with pull approach would the backup agent to play the BackupWorker role instead of the fdbserver. But it would require exposing transaction logs for some external processes, ex backup agents. Maybe these processes are neither external nor internal, they are intermediate. There are no any API and protocol for intermediate clients now, but might be good to have them.
Another possibility is to make DrWorker role that woulld be responsible to send transaction logs to dr.
However, it does have a major concern:
Now FDB has multi-region configuration (also called fearless configuration), which no long has a separate FDB cluster in the remote DC. The multi-region configuration will become the recommended configuration for high-availability service.
The DR-based backup and restore solution won’t work out of box for the multi-region configuration.
Seems we can make the same thing with the multi-region configuration: 1. stop a remote datacenter. 2. make a could copy of it. 3. restart the remote datacenter