The Configuration Backup Problem

Every network team has a story about a misconfiguration recovery that went sideways because the backup was stale, incomplete, or stored in some engineer’s home directory. Pulling configs from a multi-vendor environment shouldn’t require bespoke expect scripts for each platform — scripts where the TFTP timeout handling differs between your Cisco ASR edge routers and your Juniper QFX datacenter switches.

When your backup logic lives inside imperative Python scripts or complex Ansible playbooks, every OS update becomes a risk. One changed CLI prompt can silently break your entire backup pipeline.

Declarative Configuration Backups with Netpicker

Netpicker brings the same operator-owned YAML approach to configuration backups that it applies to firmware distribution. Instead of scripting the mechanics of each transfer, you declare the intent. Netpicker handles vendor-specific CLI variations, prompt handling, and protocol fallbacks.

For configuration backups, the workflow pulls the running configuration from the device and saves it directly to your version-controlled repository. Here is what a production-grade backup workflow looks like:

.transfer-prompts: &prompts
  "Address or name of remote host ": ""
  "Destination username ": ""
  "Destination file": ""

protocols:
  default:
    initial_context:
      src_file: startup-config

    initialize:
      - command: copy running-config {src_file}
        prompts:
           <<: *prompts

    transfers:
      tftp:
        - command: "copy {src_file} tftp://{dst_ip}/{dst_file}"
          prompts:
            <<: *prompts

      ftp:
        - command: "copy {src_file} ftp://{username}:{password}@{dst_ip}:/{dst_file}"
          prompts:
            <<: *prompts

      scp:
        - command: "copy {src_file} scp://{username}:{password}@{dst_ip}:/{dst_file}"
          prompts:
            <<: *prompts
          kwargs:
            read_timeout: 120
            last_read: 10

      screen:
        - show-run: show running-config
          kwargs:
            read_timeout: 30
          ignore_patterns:
          - Building configuration

    errors:
      kibbitzer.exceptions.FileTransferError:
        - No such file or directory
        - Error opening
        - Transfer failed
        - Permission denied

      kibbitzer.exceptions.InvalidCommand:
        - "^% (.*)"

    diff-ignore:
      - Last configuration change

Why This Approach Works

  1. Out-of-Band Backups: Configuration pulls happen out-of-band, reducing CPU load on your control plane compared to heavy SNMP or API-based serialization tasks.
  2. Multi-Protocol Support: The same workflow covers TFTP, FTP, SCP, and screen-scrape fallback — letting Netpicker select the best available transport without requiring separate scripts per protocol.
  3. Diff-Aware: The diff-ignore block strips noise like timestamps from Last configuration change, so your version control history reflects meaningful config changes rather than metadata churn.
  4. Readable by Anyone: Because the logic lives in YAML rather than buried inside Python scripts, any network engineer on the team can audit, modify, or extend the backup workflow without touching code.

Get Started

Stop relying on ad-hoc scripts for configuration backups. Clone the Netpicker community repository and run your first backup workflow in minutes:

# Clone the repository
git clone https://github.com/netpicker/netpicker.git
cd netpicker

# Start the Netpicker container stack
docker-compose up -d