You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently snapper only supports ssh-push mode for sending backups to a remote server. It would be good to have ssh-pull mode as well, to get backups from a remote server.
I would like to clarify your requirement. Assume you configure snbk in SSH-push mode, and you want to transfer a backed-up snapshot from the target server back to your source device. This is already supported using snbk restore. The feature is available from v0.13.1.
You can view the man page for more details.
Does this feature meet your requirements?
Not exactly. If I'm not mistaken, snbk restore command pulls local backups that have been sent to remote, right?What I need is to initiate a backup of a subvolume on remote and pull that backup into local.
My current workaround is to configure local-only backups on remote machine and to use btrfs send and receive. However, it is inefficient due to not tracking parent subvolume information.
Sorry for the misunderstanding. I don't use either btrbk or baksnapper, and I'm quite confused about your requirement.
I guess your definitions of local and remote may be different from mine.
To better understand your use case, I want to make sure we're using the same definitions when discussing this.
Here are my definitions:
Source Filesystem: the Btrfs filesystem that contains the subvolumes and the data you want to back up.
Local: the machine that contains the source filesystem.
Target Filesystem: the Btrfs filesystem where the backed-up snapshots reside.
Target Server: the machine that contains the target filesystem.
snapperd and snbk run on Local, so:
snapperd makes snapshots on Source Filesystem.
snbk transfer sends the snapshots from Source Filesystem to Target Filesystem. (Sender: Source Filesystem; receiver: Target Filesystem)
snbk restore sends the snapshots from Target Filesystem to Source Filesystem. (Sender: Target Filesystem; receiver: Source Filesystem)
What I need is to initiate a backup of a subvolume on remote and pull that backup into local.
Let me try to map your use case onto my definitions. Do you want snbk to run on Target Server and back up the snapshots on Source Filesystem?
Yes, here is a scenario where I think this feature could come in handy: my home computer is behind CGNAT and uses a dynamic IP. On the other hand, my office computer has a public static IP, so connecting from home to the office is much easier than doing the reverse. Of course, there are various workarounds for such setups, but having an ssh-pull method available would make things more convenient.
On implementation challenge: The snapper config on the source must be locked from the code running on the target. AFAIS that is currently not possible.
Activity
jameslai-dev commentedon Sep 11, 2026
I would like to clarify your requirement. Assume you configure
snbkin SSH-push mode, and you want to transfer a backed-up snapshot from the target server back to your source device. This is already supported usingsnbk restore. The feature is available from v0.13.1.You can view the man page for more details.
Does this feature meet your requirements?
bilgincoskun commentedon Sep 11, 2026
Not exactly. If I'm not mistaken,
snbk restorecommand pulls local backups that have been sent to remote, right?What I need is to initiate a backup of a subvolume on remote and pull that backup into local.My current workaround is to configure local-only backups on remote machine and to use btrfs send and receive. However, it is inefficient due to not tracking parent subvolume information.
From what I have seen, btrbk supports this feature: https://github.com/digint/btrbk#example-fileserver-initiated-backups-from-several-hosts
Also, baksnapper seems to support this feature for snapper backups as well: https://github.com/plattfot/baksnapper#backup-from-a-remote-machine-over-ssh
jameslai-dev commentedon Sep 11, 2026
Sorry for the misunderstanding. I don't use either
btrbkorbaksnapper, and I'm quite confused about your requirement.I guess your definitions of
localandremotemay be different from mine.To better understand your use case, I want to make sure we're using the same definitions when discussing this.
Here are my definitions:
snapperdandsnbkrun on Local, so:snapperdmakes snapshots on Source Filesystem.snbk transfersends the snapshots from Source Filesystem to Target Filesystem. (Sender: Source Filesystem; receiver: Target Filesystem)snbk restoresends the snapshots from Target Filesystem to Source Filesystem. (Sender: Target Filesystem; receiver: Source Filesystem)Let me try to map your use case onto my definitions. Do you want
snbkto run on Target Server and back up the snapshots on Source Filesystem?bilgincoskun commentedon Sep 11, 2026
Yes, that is pretty much it.
aschnell commentedon Sep 16, 2026
What is the motivation? That your backup server is not reachable but the source machine is?
bilgincoskun commentedon Sep 17, 2026
Yes, here is a scenario where I think this feature could come in handy: my home computer is behind CGNAT and uses a dynamic IP. On the other hand, my office computer has a public static IP, so connecting from home to the office is much easier than doing the reverse. Of course, there are various workarounds for such setups, but having an ssh-pull method available would make things more convenient.
aschnell commentedon Oct 15, 2026
On implementation challenge: The snapper config on the source must be locked from the code running on the target. AFAIS that is currently not possible.
aschnell commentedon Oct 21, 2026
I have implemented the ssh-pull target-mode in #1206. Missing is the locking of the snapper config on the source.
Feedback is welcome.