TL;DR fdbbackup seems to require permission for parent directory of a backup url. (e.g for file:///path/to/backup, permission of /path/to do matter)
UPDATE: It seems that parent of parent directory affect the error.
$ docker run --init --rm --name=fdb-a -v fdb-a:/var/lib/foundationdb hiroshi3110/foundationdb:5.1.5-1_ubuntu-16.04 ./start.sh
Configure new cluster.
/etc/init.d/foundationdb: line 94: log_daemon_msg: command not found
/etc/init.d/foundationdb: line 100: log_end_msg: command not found
/etc/foundationdb/fdb.cluster is now using address 172.17.0.2
Time="1526304215.233771" Severity="10" LogGroup="default" Process="fdbmonitor": Started FoundationDB Process Monitor 5.1 (v5.1.5)
Database created
Then try to do fdbbackup…
$ docker exec -ti fdb-a bash
root@93f96ad9d4c0:~# mkdir backup
root@93f96ad9d4c0:~# chmod a+w backup/
root@93f96ad9d4c0:~# fdbbackup status
No previous backups found.
root@93f96ad9d4c0:~# fdbbackup start -d file:///root/backup
The backup on tag `default' was successfully submitted.
root@93f96ad9d4c0:~# fdbbackup status
The backup on tag `default' is in progress to file:///root/backup/backup-2018-05-14-13-26-05.896971.
Snapshot interval is 864000 seconds. The initial snapshot is still running.
Details:
LogBytes written - 0
RangeBytes written - 0
Last complete log version and timestamp - 149804665, 05/14/18 13:26:06
Last complete snapshot version and timestamp - N/A, N/A
Current Snapshot start version and timestamp - 149804665, 05/14/18 13:26:06
Expected snapshot end version and timestamp - 149804665, 05/14/18 13:26:06
Backup supposed to stop at next snapshot completion - Yes
Recent Errors (since initialization)
11 second(s) ago : 'Platform error' on 'file_backup_write_range'
root@93f96ad9d4c0:~# ls -l backup/
total 0
How can I do fdbbackup properly?
Thanks in advanced as always.
Would be willing to send the log file from the failing process (either here or via direct message)? By default, they are configured to go to /var/log/foundationdb, and you’d want to find the file that has Severity="40" events. You could probably also grep for platform_error.
The file may be big, in which case an excerpt from around the error will likely be sufficient in this case.
I believe the backup agents are being run with the group and user configured in foundationdb.conf. Does that user have permissions to write to the location specified? If that is indeed the problem, then I think the error message in backup status failed us a little bit here, and I can file an issue to better indicate what went wrong in status. We may still do that if your problem isn’t an issue with permissions, but in that case we should try to figure out what’s happening first.
Ah, I figured out what problem is and I got fdbbackup to work!
For the backup url file:///root/backup, last time I did only chmod a+w /root/backup, but it requireds permission for parent directory, /root.
$ docker exec -ti fdb-a bash
root@bac49c7d0f29:~# mkdir backup
root@bac49c7d0f29:~# chmod a+w backup/
root@bac49c7d0f29:~# ls -l backup
drwxrwxrwx 2 root root 4096 May 16 00:25 backup
root@bac49c7d0f29:~# fdbbackup status
No previous backups found.
root@bac49c7d0f29:~# ls -ld /root
drwx------ 1 root root 4096 May 16 00:25 /root
root@bac49c7d0f29:~# chmod 777 /root
root@bac49c7d0f29:~# ls -ld /root
drwxrwxrwx 1 root root 4096 May 16 00:25 /root
root@bac49c7d0f29:~# fdbbackup start -d file:///root/backup
The backup on tag `default' was successfully submitted.
root@bac49c7d0f29:~# fdbbackup status
The backup on tag `default' is in progress to file:///root/backup/backup-2018-05-16-00-27-23.332032.
Snapshot interval is 864000 seconds. The initial snapshot is still running.
Details:
LogBytes written - 0
RangeBytes written - 13
Last complete log version and timestamp - 119836947, 05/16/18 00:27:22
Last complete snapshot version and timestamp - 119898807, 05/16/18 00:27:22
Current Snapshot start version and timestamp - 119836947, 05/16/18 00:27:22
Expected snapshot end version and timestamp - 119836947, 05/16/18 00:27:22
Backup supposed to stop at next snapshot completion - Yes
root@bac49c7d0f29:~# ls /root/backup/
backup-2018-05-16-00-27-23.332032
It’s most likely still a permission issue. The ‘restore_start’ task first lists all of the files in the backup path and stages a list of blocks to load in a queue in the database. Can you verify that the user running the backup agents can read and list files at /root/backup/backup/backup-2018-05-16-12-26-35.824367?