Configuration Files¶
All Proxmox Backup Server configuration files resides inside directory
/etc/proxmox-backup/
.
acl.cfg
¶
File Format¶
This file contains the access control list for the Proxmox Backup Server API.
Each line starts with acl:
, followed by 4 additional values
separated by collon.
propagate: | Propagate permissions down the hierachrchy |
---|---|
path: | The object path |
User/Token: | List of users and token |
Role: | List of assigned roles |
Here is an example list:
acl:1:/:root@pam!test:Admin
acl:1:/datastore/store1:user1@pbs:DatastoreAdmin
You can use the proxmox-backup-manager acl
command to manipulate
this file.
Roles¶
The following roles exist:
Admin : | Administrator |
---|---|
Audit : | Auditor |
NoAccess : | Disable Access |
DatastoreAdmin : | Datastore Administrator |
DatastoreReader : | |
Datastore Reader (inspect datastore content and do restores) | |
DatastoreBackup : | |
Datastore Backup (backup and restore owned backups) | |
DatastorePowerUser : | |
Datastore PowerUser (backup, restore and prune owned backup) | |
DatastoreAudit : | Datastore Auditor |
RemoteAudit : | Remote Auditor |
RemoteAdmin : | Remote Administrator |
RemoteSyncOperator : | |
Syncronisation Opertator | |
TapeAudit : | Tape Auditor |
TapeAdmin : | Tape Administrator |
TapeOperator : | Tape Operator |
TapeReader : | Tape Reader |
datastore.cfg
¶
File Format¶
The file contains a list of datastore configuration sections. Each
section starts with a header datastore: <name>
, followed by the
datastore configuration options.
datastore: <name1>
path <path1>
<option1> <value1>
...
datastore: <name2>
path <path2>
...
You can use the proxmox-backup-manager datastore
command to manipulate
this file.
Options¶
Required properties:
path
:<string>
- Directory name
Optional properties:
comment
:<string>
- Comment (single line).
gc-schedule
:<calendar-event>
- Run garbage collection job at specified schedule.
keep-daily
:<integer> (1 - N)
- Number of daily backups to keep.
keep-hourly
:<integer> (1 - N)
- Number of hourly backups to keep.
keep-last
:<integer> (1 - N)
- Number of backups to keep.
keep-monthly
:<integer> (1 - N)
- Number of monthly backups to keep.
keep-weekly
:<integer> (1 - N)
- Number of weekly backups to keep.
keep-yearly
:<integer> (1 - N)
- Number of yearly backups to keep.
notify
:[[gc=<enum>] [,sync=<enum>] [,verify=<enum>]]
Datastore notification setting
gc
=never|always|error
- When do we send notifications
sync
=never|always|error
- When do we send notifications
verify
=never|always|error
- When do we send notifications
notify-user
:<string>
- User ID
prune-schedule
:<calendar-event>
- Run prune job at specified schedule.
verify-new
:<boolean>
- If enabled, all backups will be verified right after completion.
user.cfg
¶
File Format¶
This file contains the list of API users and API tokens.
Each user configuration section starts with a header user: <name>
,
followed by the user configuration options.
API token configuration starts with a header token:
<userid!token_name>
, followed by the token configuration. The data
used to authenticate tokens is stored in a separate file
(token.shadow
).
user: root@pam
comment Superuser
email test@example.local
...
token: root@pam!token1
comment API test token
enable true
expire 0
user: ...
You can use the proxmox-backup-manager user
command to manipulate
this file.
Options¶
Section type 'user
': User properties.
Optional properties:
comment
:<string>
- Comment (single line).
email
:<string>
- E-Mail Address.
enable
:<boolean> (default=true)
- Enable the account (default). You can set this to '0' to disable the account.
expire
:<integer> (0 - N) (default=0)
- Account expiration date (seconds since epoch). '0' means no expiration date.
firstname
:<string>
- First name.
lastname
:<string>
- Last name.
Section type 'token
': ApiToken properties.
Optional properties:
comment
:<string>
- Comment (single line).
enable
:<boolean> (default=true)
- Enable the account (default). You can set this to '0' to disable the account.
expire
:<integer> (0 - N) (default=0)
- Account expiration date (seconds since epoch). '0' means no expiration date.
remote.cfg
¶
File Format¶
This file contains information used to access remote servers.
Each entry starts with a header remote: <name>
, followed by the
remote configuration options.
remote: server1
host server1.local
auth-id sync@pbs
...
remote: ...
You can use the proxmox-backup-manager remote
command to manipulate
this file.
Options¶
Required properties:
auth-id
:<string>
- Authentication ID
host
:<string>
- DNS name or IP address.
password
:<string>
- Password or auth token for remote host.
Optional properties:
comment
:<string>
- Comment (single line).
fingerprint
:<string>
- X509 certificate fingerprint (sha256).
port
:<integer>
- The (optional) port
sync.cfg
¶
File Format¶
Each entry starts with a header sync: <name>
, followed by the
job configuration options.
sync: job1
store store1
remote-store store1
remote lina
sync: ...
You can use the proxmox-backup-manager sync-job
command to manipulate
this file.
Options¶
Required properties:
remote
:<string>
- Remote ID.
remote-store
:<string>
- Datastore name.
store
:<string>
- Datastore name.
Optional properties:
comment
:<string>
- Comment (single line).
owner
:<string>
- Authentication ID
remove-vanished
:<boolean> (default=true)
- Delete vanished backups. This remove the local copy if the remote backup was deleted.
schedule
:<calendar-event>
- Run sync job at specified schedule.
verification.cfg
¶
File Format¶
Each entry starts with a header verification: <name>
, followed by the
job configuration options.
verification: verify-store2
ignore-verified true
outdated-after 7
schedule daily
store store2
verification: ...
You can use the proxmox-backup-manager verify-job
command to manipulate
this file.
Options¶
Required properties:
store
:<string>
- Datastore name.
Optional properties:
comment
:<string>
- Comment (single line).
ignore-verified
:<boolean> (default=true)
- Do not verify backups that are already verified if their verification is not outdated.
outdated-after
:<integer> (1 - N)
- Days after that a verification becomes outdated
schedule
:<calendar-event>
- Run verify job at specified schedule.