FASTBCP_BACKUP_RESTORE_MODE
Overview
Since FastBCP 1.6.7, --connectiontype backup_mssql reads the latest version of a table among the files you give it. When a backup that could be the newest cannot be used, the export fails and names it, rather than reading older data without saying so.
The FASTBCP_BACKUP_RESTORE_MODE environment variable changes that without touching the command. Set it to best_effort to skip that backup and read the newest version that can be used.
Syntax
- Windows
- Linux
$env:FASTBCP_BACKUP_RESTORE_MODE = "best_effort"
export FASTBCP_BACKUP_RESTORE_MODE=best_effort
Configuration
| Property | Value |
|---|---|
| Values | strict or best_effort, in any case. Any other value stops the run at startup with a message naming the variable |
| Default | Not set: strict |
| Applies to | --connectiontype backup_mssql |
| Since | FastBCP 1.6.7 |
| Value | A backup that could be the newest and cannot be used |
|---|---|
strict | The export fails, naming the backup, and the logs say what can be done about it |
best_effort | It is skipped, and the newest usable version is read, however old |
What FastBCP Logs
At the start of each export:
Backup version to read : restore point "latest", restore mode "strict"
With strict, a refusal is followed by a warning with the ways out. With best_effort, a warning at the start of each export says that older rows may be read.
best_effort skippedThe backups skipped are reported on the standard error output only, not in the FastBCP logs. A job that captures only the logs sees that this can happen, not that it did: keep the standard error output of the job if you use this mode.
best_effort needs another version to read. A full backup alone that lost the end of its file fails with this mode too, and the logs then point to FASTBCP_BACKUP_RESTORE_POINT=full.
With --sourceconnectstring
An adbc.arpemsbackup.restore_mode option in --sourceconnectstring wins over the variable.