GNIZA - Linux Backup Manager

A complete Linux backup solution that works as a stand-alone backup tool or a centralized backup server. Pull files from local directories, remote SSH servers, S3 buckets, Google Drive, or Google Photos, and push them to any combination of SSH, local, S3, Google Drive, or Google Photos destinations — all with incremental rsync snapshots, hardlink deduplication, and automatic retention.

Manage everything through a terminal UI, web dashboard, or CLI.

Features

Stand-alone or backup server — Back up the local machine, or pull from remote servers without installing anything on them
Remote sources — Pull files from SSH servers, S3 buckets, Google Drive, or Google Photos before backing up
Multiple destination types — Push to SSH, local drives (USB/NFS), S3 (AWS, Backblaze B2, Wasabi), Google Drive, or Google Photos
Auto remote configuration — Two methods: Direct SSH Setup (provide SSH credentials, GNIZA configures the remote server automatically) or Via Remote Script (run a setup script on the remote, transfer config via croc) — no manual SSH key or config entry needed
Incremental snapshots — rsync --link-dest hardlink deduplication across snapshots
MySQL/MariaDB backup — Dump all or selected databases with grants, routines, and triggers
PostgreSQL backup — Dump all or selected databases with roles via pg_dump + gzip
Atomic snapshots — .partial directory during transfer, renamed on success
Retention policies — Automatic pruning per-schedule with global default and snapshot pinning
Disk space safety — Abort if destination usage exceeds threshold (default 95%)
Pre/post hooks — Run shell commands before and after each backup
Cron scheduling — Hourly, daily, weekly, monthly, or custom cron expressions
Multi-channel notifications — Email (SMTP/system mail), Telegram, Webhook (Slack/Discord/generic), ntfy, and Healthchecks.io on failure or every run
Digest notifications — Daily/weekly/monthly summary of all backup jobs with stat boxes, failed sources, and per-job details sent via all configured channels
Stale backup alerts — Get notified when a source hasn't been backed up within a configurable window
Bandwidth limiting — Global or per-destination KB/s cap
Retry logic — Automatic SSH reconnection with exponential backoff
Include/exclude filters — Rsync glob patterns per source
Terminal UI — Full-featured TUI powered by Textual
Web dashboard — Browser-based dashboard with system stats (CPU, Memory, multi-partition Disks, IO Wait, Network), plus full backup management. All tables are sortable by clicking column headers. Source list shows disk usage per source (local, SSH, and rclone)
CLI — Scriptable commands for automation and cron
Root and user mode — System-wide (/etc/gniza) or per-user (~/.config/gniza)

Use Cases

Stand-alone backup — Install gniza on any Linux server or workstation. Define local folders as sources and back them up to an SSH server, USB drive, S3, Google Drive, or Google Photos.

Backup server — Install gniza on a central server. Define remote SSH sources pointing to your production servers. gniza pulls their files and stores snapshots on local drives or cloud storage — no agent needed on the source machines.

Hybrid — Mix local and remote sources in the same installation. Back up local configs alongside files pulled from multiple remote servers, all managed from one place.

Installation

One-Line Installer (any Linux)

curl -sSL https://git.linux-hosting.co.il/shukivaknin/gniza4linux/raw/branch/main/scripts/install.sh | sudo bash

The installer handles dependencies, config directories, Python venv, web dashboard, and systemd services. User mode (no root): remove sudo.

APT Repository (Debian/Ubuntu)

curl -fsSL https://deb.gniza.app/gniza.gpg | sudo gpg --dearmor -o /usr/share/keyrings/gniza-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/gniza-archive-keyring.gpg] https://deb.gniza.app stable main" | sudo tee /etc/apt/sources.list.d/gniza.list
sudo apt update && sudo apt install gniza

Supports: Debian stable, bookworm, trixie, and Ubuntu noble, jammy. Updates via sudo apt upgrade gniza.

DNF/YUM Repository (RHEL/AlmaLinux/Rocky/Fedora)

sudo tee /etc/yum.repos.d/gniza.repo << 'EOF'
[gniza]
name=GNIZA Backup Manager
baseurl=https://rpm.gniza.app
enabled=1
gpgcheck=0
EOF
sudo dnf install gniza    # or: sudo yum install gniza

To update: sudo dnf upgrade gniza

From Source

git clone https://git.linux-hosting.co.il/shukivaknin/gniza4linux.git
cd gniza4linux && sudo bash scripts/install.sh

Root mode installs to /usr/local/gniza. User mode installs to ~/.local/share/gniza.

Uninstall

# Debian/Ubuntu package
sudo apt remove gniza      # remove (keeps config/logs)
sudo apt purge gniza       # full removal

# RHEL/AlmaLinux/Rocky/Fedora
sudo dnf remove gniza

# Script-based install
gniza uninstall

Dependencies

Required: bash 4+, rsync
Optional: ssh, curl (SMTP/Telegram/Webhook/ntfy/Healthchecks notifications), sshpass (password auth and Direct SSH auto-configure), rclone (S3/Google Drive/Google Photos), croc (auto remote configuration via remote script)
TUI/Web: python3, textual, textual-serve (installed automatically)

Quick Start

# Launch the TUI
gniza

# Start the web dashboard
gniza web install-service
gniza web start
# Access at http://<server-ip>:2323

# Or use the CLI to add a source and destination
gniza --cli sources add --name=mysite --folders=/var/www,/etc/nginx
gniza --cli destinations add --name=backup-server

# Run a backup
gniza --cli backup --source=mysite
gniza --cli backup --all

Terminal UI

Launch with gniza (no arguments). The TUI provides:

Sources — Create, edit, delete backup sources with folder browser (local, SSH, and rclone) and Test & Save connection validation
Destinations — Configure SSH, local, S3, Google Drive, or Google Photos destinations with Test & Save connection validation
Backup — Run backups with source/destination selection
Restore — Browse snapshots and restore to original location or custom directory
Running Tasks — Monitor active backup/restore jobs with live log output. Jobs show "Skipped" when all targets are disabled
Schedules — Manage cron schedules with time/day pickers and toggle switches
Snapshots — Browse and manage stored snapshots
Logs — View backup history with pagination and status detection (success/error/skipped)
Settings — Configure global options
Setup Wizard — Guided first-run configuration

The TUI adapts to terminal width, with an inline documentation panel on wide screens and a help modal on narrow ones.

Web Dashboard

A full-featured web dashboard built with Flask, DaisyUI, and HTMX. All three interfaces (TUI, Web, CLI) maintain full feature parity.

gniza web install-service   # Install systemd service (port 2323)
gniza web start             # Start the service
gniza web status            # Check status

Access at http://<server-ip>:2323. Credentials are stored in gniza.conf as WEB_USER and WEB_API_KEY (password).

Supports both root (system service) and user (user service) modes.

Background Daemon

The gniza daemon runs periodic health checks in the background — detecting dead jobs, dispatching queued jobs, and cleaning up old logs and registry entries.

gniza daemon install-service   # Install systemd service (auto-starts on boot)
gniza daemon start             # Start manually in foreground
gniza daemon status            # Check status

Supports both root (system service) and user (user service) modes. Configure the check interval in gniza.conf:

DAEMON_INTERVAL=10             # Health check interval in seconds (default: 10)

How Incremental Backups Work

gniza uses rsync's --link-dest option to create space-efficient incremental backups using hardlinks.

The first backup copies every file from source to destination. This takes the most time and disk space. Depending on data size and network speed, the initial backup may take a long time — this is normal.

Every subsequent backup is significantly faster. Rsync compares each file against the previous snapshot. Unchanged files are not transferred — instead, rsync creates a hardlink to the same data block from the previous snapshot. Only new or modified files are copied.

This means:

Each snapshot appears as a complete directory tree — browse or restore any snapshot independently
Unchanged files share disk space through hardlinks, so 10 snapshots of 50 GB with minor changes might use 55 GB total instead of 500 GB
Deleting an old snapshot only frees space for files not referenced by other snapshots
Subsequent backups typically finish in seconds or minutes rather than hours

Example: A first backup of 20 GB takes 45 minutes over SSH. The next day, only 200 MB changed — the second backup takes under 2 minutes and uses only 200 MB of additional disk space, while still appearing as a complete 20 GB snapshot.

Remote Sources

gniza can pull files from remote machines without installing anything on them. This turns gniza into a centralized backup server.

SSH Source

Back up a remote server by pulling files over SSH:

Create a source with TARGET_SOURCE_TYPE="ssh"
Set the SSH connection details (TARGET_SOURCE_HOST, etc.)
Set TARGET_FOLDERS to the remote paths you want to back up (e.g. /var/www,/etc)

gniza connects to the remote server, pulls the specified folders to a local staging area, then pushes the data to the configured destination using the standard snapshot pipeline.

Gniza4linux

Install / Use

README