Incus copy to remote server

Hi all,

I have a question. I installed a second incus server. However when i am doing a snapshot copy to the remote and start it i see the network settings are not copied. So the container is using a dhcp adres instead of a fixed thas is originaly used in the source container.

How can i copy these settings also?

Can you show:

  • incus config show NAME on the target server
  • incus config show NAME --expanded on the target server
  • incus snapshot show NAME SNAPSHOT on the source server

incus config show NAME:

Blockquote
root@incusbackupserver:~# incus config show warehouse
architecture: x86_64
config:
boot.autostart: “true”
boot.autostart.delay: “30”
boot.autostart.priority: “91”
image.architecture: amd64
image.description: Debian bookworm amd64 (20240408_05:24)
image.os: Debian
image.release: bookworm
image.serial: “20240408_05:24”
image.type: squashfs
image.variant: cloud
security.nesting: “true”
security.privileged: “true”
volatile.apply_template: copy
volatile.base_image: ffc8068a94d5f69a6e1dca7ed7997af22ea564473e08799523501147fad1d921
volatile.cloud-init.instance-id: 2c29b060-f325-4891-8724-8e4a03df9b94
volatile.eth0.hwaddr: 00:16:3e:33:7e:7a
volatile.idmap.base: “0”
volatile.idmap.next: ‘
volatile.last_state.idmap: ‘
volatile.uuid: e650c976-b270-45d5-8cd5-fd01234c99ea
volatile.uuid.generation: e650c976-b270-45d5-8cd5-fd01234c99ea
devices: {}
ephemeral: false
profiles:

  • default
  • cpu4-memory32
  • snap-daily
    stateful: false
    description: “”

incus config show NAME --expanded

Blockquote
root@incusbackupserver:~# incus config show warehouse --expanded
architecture: x86_64
config:
boot.autostart: “true”
boot.autostart.delay: “30”
boot.autostart.priority: “91”
image.architecture: amd64
image.description: Debian bookworm amd64 (20240408_05:24)
image.os: Debian
image.release: bookworm
image.serial: “20240408_05:24”
image.type: squashfs
image.variant: cloud
limits.cpu: “4”
limits.memory: 32GB
security.nesting: “true”
security.privileged: “true”
snapshots.expiry: 1d
snapshots.schedule: 0 4 * * *
volatile.apply_template: copy
volatile.base_image: ffc8068a94d5f69a6e1dca7ed7997af22ea564473e08799523501147fad1d921
volatile.cloud-init.instance-id: 2c29b060-f325-4891-8724-8e4a03df9b94
volatile.eth0.hwaddr: 00:16:3e:33:7e:7a
volatile.idmap.base: “0”
volatile.idmap.next: ‘
volatile.last_state.idmap: ‘
volatile.uuid: e650c976-b270-45d5-8cd5-fd01234c99ea
volatile.uuid.generation: e650c976-b270-45d5-8cd5-fd01234c99ea
devices:
eth0:
name: eth0
nictype: macvlan
parent: enp3s0
type: nic
root:
path: /
pool: default
type: disk
ephemeral: false
profiles:

  • default
  • cpu4-memory32
  • snap-daily
    stateful: false
    description: “”

Blockquote

incus snapshot show NAME SNAPSHOT
root@esx:~# incus snapshot show warehouse snap0
expires_at: 2024-06-24T00:01:25.54624472+02:00
architecture: x86_64
config:
boot.autostart: “true”
boot.autostart.delay: “30”
boot.autostart.priority: “91”
image.architecture: amd64
image.description: Debian bookworm amd64 (20240408_05:24)
image.os: Debian
image.release: bookworm
image.serial: “20240408_05:24”
image.type: squashfs
image.variant: cloud
security.nesting: “true”
security.privileged: “true”
volatile.base_image: ffc8068a94d5f69a6e1dca7ed7997af22ea564473e08799523501147f ad1d921
volatile.cloud-init.instance-id: 75215f10-db3a-4b9a-879b-d08fb368b1e1
volatile.eth0.host_name: veth374789ff
volatile.eth0.hwaddr: 00:16:3e:92:22:16
volatile.idmap.base: “0”
volatile.idmap.current: ‘
volatile.idmap.next: ‘
volatile.last_state.idmap: ‘
volatile.last_state.power: RUNNING
volatile.uuid: 16350578-5e14-44ca-ba3f-86cea62e0115
volatile.uuid.generation: 16350578-5e14-44ca-ba3f-86cea62e0115
created_at: 2024-06-22T22:01:25.546787526Z
devices: {}
ephemeral: false
expanded_config:
boot.autostart: “true”
boot.autostart.delay: “30”
boot.autostart.priority: “91”
image.architecture: amd64
image.description: Debian bookworm amd64 (20240408_05:24)
image.os: Debian
image.release: bookworm
image.serial: “20240408_05:24”
image.type: squashfs
image.variant: cloud
limits.cpu: “4”
limits.memory: 32GB
security.nesting: “true”
security.privileged: “true”
snapshots.expiry: 1d
snapshots.schedule: 0 0 * * *
volatile.base_image: ffc8068a94d5f69a6e1dca7ed7997af22ea564473e08799523501147f ad1d921
volatile.cloud-init.instance-id: 75215f10-db3a-4b9a-879b-d08fb368b1e1
volatile.eth0.host_name: veth374789ff
volatile.eth0.hwaddr: 00:16:3e:92:22:16
volatile.idmap.base: “0”
volatile.idmap.current: ‘
volatile.idmap.next: ‘
volatile.last_state.idmap: ‘
volatile.last_state.power: RUNNING
volatile.uuid: 16350578-5e14-44ca-ba3f-86cea62e0115
volatile.uuid.generation: 16350578-5e14-44ca-ba3f-86cea62e0115
expanded_devices:
eth0:
name: eth0
nictype: bridged
parent: bridge1
type: nic
root:
path: /
pool: default
type: disk
last_used_at: 0001-01-01T00:00:00Z
name: snap0
profiles:

  • default
  • cpu4-memory32
  • snap-daily
    stateful: false
    size: 5914624

Blockquote

@stgraber

Right, so that shows that your instance itself (and its snapshot) don’t contain any devices.
All your devices are inherited from profiles instead.

On your source system, you have an eth0 device bridged to bridge1 coming from one of your profiles. On the target, you have an eth0 device using macvlan on top of enp3s0 instead.

i allredeay understand. If i do not run the container on the remote server then everything is ok.

One question. If i want to backup the full incus machine what do i need to backup? i use zfs so could i create a snapshot of

  • incus storage pool
  • /var/lib/incus

would this be enough? of do i need to backup more than this?