Incremental backups
Incremental backups An incremental backup stores only what changed since the previous backup. After a full backup, each run carries just the new and changed files, Docker volume files and container images, so backups are smaller and faster, and a stack that is stopped for the copy is down for less time. Any backup can still be restored to its exact state: BackupMunk applies the full backup and the incrementals after it in order, and removes files that had been deleted by then. Incremental backups need a license. Turn it on In the backup's Options step, choose Backup type → Incremental, then decide when a new full backup starts: Setting What it does Full backup every N runs The default is every 7 runs: a full backup, then 6 incrementals. Full backup on a schedule A second schedule, for example Sunday 02:00, in the backup's time zone. Incrementals run on the normal schedule. At most this many backups per chain A hard limit (default 30) whatever the schedule, so a chain can't grow forever. A full backup and the incrementals after it form a chain. Shorter chains restore faster; longer ones store less. BackupMunk also takes a full backup on its own when an incremental wouldn't be safe: it's the first backup of this job on this client, the previous backup is missing on one of the backup's destinations, what the backup covers changed (paths, compose file, volumes, images or filters), the client has no record of the previous backup (for example, after reinstalling the agent). To start a new chain now, open the client's page and choose Run a full backup now next to the backup. What is stored incrementally Files and folders, including the compose file, its env files and bind-mounted folders. A file counts as changed when its size, modification time, change time, inode, permissions, owner or symlink target differ. Docker named volumes, file by file, when the agent can read the volume's files on the host — the usual case for Docker Engine on Linux with the agent running as root. Volumes it can't read that way (other volume drivers, Docker Desktop, user-namespace remapping) are stored whole in every backup; the run log says which. Container images: only images whose ID changed are saved again. A changed file is stored whole. Large files that change all the time, such as a database's data files, gain little; for databases, a dump in a backed-up folder or a stopped or checkpointed copy works better. Restore Restore any backup from the Backups page as usual. For an incremental, the restore dialog tells you how many backups will be applied, and the client applies the chain's full backup and each incremental in order. The target client needs agent 0.6.58 or later. The Backups page marks each backup full or incremental #n, and not restorable when a backup it depends on is missing from that destination (BackupMunk re-creates missing copies from other destinations when it can). Offline with bmrecover bmrecover restores a chain without the server. Download the chain's full backup and every incremental up to the one you want, then pass them all with --chain, in any order: Given an incremental on its own, bmrecover refuses and tells you which backups it needs. Volume files go to ./restored/volumes/<name>/, or straight into Docker with --docker. Retention Keep latest N backups on a destination keeps the newest N backups of each backup on each client and never deletes a backup that a kept incremental still depends on. A destination can therefore hold more than N backups of a job: up to N plus the rest of the oldest kept chain. See Retention. [!WARNING] Don't add bucket lifecycle or expiration rules to a destination that holds incremental backups. They can delete a full backup that newer incrementals need. If that happens, those incrementals are marked not restorable and the next backup is a full one. See also: Create a backup and Restore backups.
BackupMunk Enterprise documentation