Forem: Ashraf Mehdaly

Designing a Restore-First Desktop Backup Tool Around Restic (From Bash Script to Qt/C++)

Ashraf Mehdaly — Sun, 22 Feb 2026 20:56:21 +0000

Reflections on trust, restore safety, threading, and building a desktop orchestration layer around a CLI engine.

Backups Are Easy. Restores Are Not.

Taking backups is usually simple.

Restoring them — confidently, correctly, and without hesitation — is where anxiety begins.

Over time, I realized that most tools are designed around creating backups. Very few are designed around restoring safely. And psychologically, restore confidence is what really matters.

This realization is what led me from a small Bash script wrapped in KDialog to a full multithreaded Qt/C++ desktop application built around restic.

Phase 1: The Script That Solved One Problem

The first version of this project was nothing more than:

A Bash script
Hardcoded include paths
restic CLI calls
KDialog progress dialogs

It removed repetitive typing. That was enough — for a while.

But as I started using restic to manage configuration state (Docker stacks, system configs, reverse proxies, etc.), new requirements emerged:

Multiple structured backup definitions
Clean separation between “what to back up” and “how to execute”
Safer restore workflows
Snapshot comparison
Elevated execution handling
Persistence beyond flat config files

The script had reached its natural limits.

The Philosophy: Orchestrator, Not Engine

One rule shaped everything that followed:

Restic remains the engine. The application must remain an orchestrator.

I did not want:

A custom backup format
A metadata layer that breaks CLI compatibility
Tight coupling to restic internals
A forked engine

Repositories remain 100% standard restic repositories.

You can always use the CLI directly.

This separation is intentional. It preserves transparency and trust.

Why Qt/C++?

The move to Qt Widgets + C++ was pragmatic:

Cross-platform (Linux + Windows)
Strong threading primitives
Clean process management (QProcess)
Mature event system
Deterministic memory ownership

This was not about building something flashy.

It was about building something predictable.

Backup software should feel boring — in the best possible way.

Threading and Process Isolation

One non-negotiable requirement:

The UI must never block during backup or restore operations.

Architecture:

UI Thread

→ Operation Controller

→ Worker Object (QObject-based)

→ QThread

→ QProcess (restic invocation)

Key principles:

Restic runs as an external process.
Output streams are parsed asynchronously.
No nested event loops.
No UI updates from worker threads.
Strict signal-slot boundaries.

This preserves responsiveness and reduces risk of undefined state during long operations.

The application does not embed restic. It orchestrates it.

Profiles as “State Definitions”

The biggest conceptual shift from the Bash prototype was introducing structured profiles.

A profile defines:

Repository path
Multiple include directories
Selective file includes
Glob-based exclude patterns
Pre/Post scripts
Elevation requirements
Default restore behavior

Instead of thinking in terms of “run backup command”, I started thinking in terms of:

Define the state of a machine.

For example:

Profile: docker-host-01

Includes:

/etc/docker
/srv/docker-compose
/etc/nginx
specific .env files

Excludes:

/logs/
/cache/
transient runtime directories

This allows treating configuration as versioned infrastructure.

Restore Is a First-Class Citizen

Most CLI usage patterns focus on restic backup.

I chose to design the UI around restore semantics.

Two restore modes emerged:

Mirror Mode

The target directory becomes identical to the snapshot.

Useful for:

Rebuilding a machine
Migrating to a clean VM
Rehydrating configuration state

Update Mode

Only overwrite files that exist in the snapshot.

Useful for:

Partial correction
Non-destructive repair
Controlled restoration

Internally, restore operations are staged and validated before final application.

Restore must feel deliberate — not destructive.

Snapshot Diff and File-Level Diff

Restic already tracks content efficiently.

But understanding what changed is equally important.

The application can:

Compare two snapshots
Identify added/modified/deleted files
Extract specific file versions
Perform file-level diff analysis

This turns backups into something closer to version history.

For configuration-heavy environments, this visibility matters.

Elevated Execution and Hooks

System paths often require root/admin access.

The application supports:

Explicit elevated execution
Controlled privilege escalation
Pre/Post scripts per profile

Examples:

Stop Docker before backup
Dump a database before snapshot
Restart services after restore

These are not advanced features — they are practical realities in homelab and system environments.

Automation without context can be dangerous.

Controlled hooks provide flexibility without losing structure.

Persistence and Portability

SQLite is used for:

Profile definitions
Operation history
Application settings

Import/Export allows moving profile definitions between machines.

The repository remains external and portable.

The application’s state is separate from backup data.

Again — boundaries matter.

Build System and Determinism

The project uses CMake with clear target separation:

Core execution module
Worker module
UI module
Database layer

Shared library outputs are controlled explicitly.
No versioned SONAME chains where unnecessary.
Deployment artifacts are predictable.

Backup tooling should not surprise the user — including at build time.

A Calm Conclusion

This project evolved gradually:

Bash script → structured orchestration → multi-threaded Qt desktop application.

The most important insight was not about threading or CMake.

It was this:

Backup software is about confidence.

Confidence comes from:

Predictable behavior
Clear boundaries
Restore safety
Transparency
Compatibility

Restic remains the engine.

The desktop layer exists to improve workflow — not to obscure it.

If there is one architectural lesson here, it is this:

When wrapping a CLI tool with a GUI, preserve the engine’s integrity — and design around the human moment of restore.

Project Reference

I packaged this into a desktop application called EasyBackupManager (EBM).

If you're curious to explore it, see screenshots, or try the Windows/Linux builds which is completely free, you can find it here:

https://easybackupmanager.com

The repositories remain fully standard restic repositories and are always accessible via the CLI.

Adding Middleware to .NET Desktop Applications

Ashraf Mehdaly — Sat, 22 Jun 2024 18:51:37 +0000

Middleware is a common pattern in web development for handling cross-cutting concerns like logging, authentication, and error handling. However, in desktop applications, the concept isn't as directly supported. This article explores how you can implement middleware-like behavior in .NET desktop applications using several design patterns and strategies.

Event Handling Middleware

One approach to implementing middleware in a .NET desktop application is through event handling. By intercepting and handling events centrally, you can insert middleware logic before the main application logic.

Example

public class Middleware
{
    public void Process(object sender, EventArgs e)
    {
        // Middleware logic
        Console.WriteLine("Middleware processing...");
    }
}

public class MainApplication
{
    public event EventHandler SomeEvent;

    public MainApplication()
    {
        Middleware middleware = new Middleware();
        SomeEvent += middleware.Process;
        SomeEvent += MainLogic;
    }

    public void MainLogic(object sender, EventArgs e)
    {
        // Main application logic
        Console.WriteLine("Main logic processing...");
    }

    public void TriggerEvent()
    {
        SomeEvent?.Invoke(this, EventArgs.Empty);
    }
}

In this example, the Middleware class intercepts the SomeEvent event before the MainLogic method processes it. This allows you to insert any necessary preprocessing logic.

Decorator Pattern Middleware

The decorator pattern is another effective way to add middleware-like behavior. This pattern involves wrapping functionality around specific methods, which can be particularly useful for key operations in your application.

Example

public interface IComponent
{
    void Execute();
}

public class MainComponent : IComponent
{
    public void Execute()
    {
        // Main application logic
        Console.WriteLine("Executing main component...");
    }
}

public class MiddlewareDecorator : IComponent
{
    private readonly IComponent _component;

    public MiddlewareDecorator(IComponent component)
    {
        _component = component;
    }

    public void Execute()
    {
        // Middleware logic before
        Console.WriteLine("Executing middleware before...");

        _component.Execute();

        // Middleware logic after
        Console.WriteLine("Executing middleware after...");
    }
}

// Usage
var mainComponent = new MainComponent();
var decoratedComponent = new MiddlewareDecorator(mainComponent);
decoratedComponent.Execute();

In this pattern, the MiddlewareDecorator wraps around the MainComponent, allowing you to insert logic before and after the main execution.

Pipeline Pattern Middleware

For a more structured approach, you can implement a pipeline pattern. This involves creating a series of middleware components that each process a request and pass it to the next component in the pipeline.

Example

public interface IMiddleware
{
    void Invoke(Context context, Action next);
}

public class Context
{
    // Context properties
}

public class Middleware1 : IMiddleware
{
    public void Invoke(Context context, Action next)
    {
        // Middleware logic
        Console.WriteLine("Middleware 1 processing...");
        next();
    }
}

public class Middleware2 : IMiddleware
{
    public void Invoke(Context context, Action next)
    {
        // Middleware logic
        Console.WriteLine("Middleware 2 processing...");
        next();
    }
}

public class Pipeline
{
    private readonly List<IMiddleware> _middlewares = new List<IMiddleware>();
    private int _currentMiddleware = -1;

    public void Use(IMiddleware middleware)
    {
        _middlewares.Add(middleware);
    }

    public void Execute(Context context)
    {
        _currentMiddleware = -1;
        Next(context);
    }

    private void Next(Context context)
    {
        _currentMiddleware++;
        if (_currentMiddleware < _middlewares.Count)
        {
            _middlewares[_currentMiddleware].Invoke(context, () => Next(context));
        }
    }
}

// Usage
var pipeline = new Pipeline();
pipeline.Use(new Middleware1());
pipeline.Use(new Middleware2());

var context = new Context();
pipeline.Execute(context);

In this pipeline pattern, each IMiddleware component processes the Context and then calls the next middleware in the sequence.

Conclusion

While .NET desktop applications don't natively support middleware in the same way that web frameworks like ASP.NET Core do, you can still implement middleware-like behavior using event handling, the decorator pattern, or a custom pipeline. These strategies allow you to modularize and manage cross-cutting concerns such as logging, exception handling, and more in a clean and maintainable way.

By adopting these patterns, you can improve the structure and scalability of your desktop applications, making them easier to maintain and extend over time.

Unraveling the Enigma: Exploring Object Equality in JavaScript and Beyond

Ashraf Mehdaly — Sat, 22 Jul 2023 08:00:39 +0000

Introduction:
JavaScript is a widely used programming language known for its flexibility and dynamic nature. However, when it comes to object comparison, JavaScript can behave in unexpected ways. One peculiar aspect is that two seemingly similar objects are not considered equal when using the equality operator (==) or strict equality operator (===). This essay explores the reasons behind this behavior and compares it with other programming languages like C#.

1. Reference Equality in JavaScript:
In JavaScript, objects are reference types, and when comparing objects using the equality operator (==) or the strict equality operator (===), the comparison is based on their references rather than their contents. Two objects with identical key-value pairs are considered different if they occupy different memory locations. Let's illustrate this with a code example:

const obj1 = { name: "John", age: 30 };
const obj2 = { name: "John", age: 30 };

console.log(obj1 == obj2); // Output: false
console.log(obj1 === obj2); // Output: false

In this example, obj1 and obj2 have the same key-value pairs, but they are two distinct objects with different references. Hence, the comparison yields false.

2. Value Equality in JavaScript:
If you want to compare the contents of two objects rather than their references, you need to implement a custom comparison function. One way to achieve this is by converting the objects to JSON strings and then comparing those strings. However, this approach has limitations, especially when dealing with nested objects or functions.

function areObjectsEqual(obj1, obj2) {
  return JSON.stringify(obj1) === JSON.stringify(obj2);
}

const obj3 = { name: "John", age: 30 };
const obj4 = { name: "John", age: 30 };

console.log(areObjectsEqual(obj3, obj4)); // Output: true

3. Object Comparison in C#:
C# is a statically typed language, and its object comparison behavior is different from JavaScript. By default, object comparisons in C# are reference-based, similar to JavaScript's strict equality (===). However, C# allows you to override the Equals method to customize object comparison based on their contents.

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    public override bool Equals(object obj)
    {
        if (obj == null || !(obj is Person))
            return false;

        var otherPerson = (Person)obj;
        return this.Name == otherPerson.Name && this.Age == otherPerson.Age;
    }
}

Person person1 = new Person { Name = "John", Age = 30 };
Person person2 = new Person { Name = "John", Age = 30 };

Console.WriteLine(person1 == person2); // Output: False
Console.WriteLine(person1.Equals(person2)); // Output: True

In this example, we override the Equals method in the Person class to compare the objects based on their Name and Age properties.

Conclusion:
In JavaScript, two similar objects are not considered equal when using the equality or strict equality operators because the comparison is based on their references, not their contents. To compare object contents in JavaScript, you need to implement a custom comparison function. On the other hand, C# allows developers to override the Equals method to customize object comparisons based on their properties. Understanding these differences is crucial for writing robust code when dealing with objects in JavaScript and other programming languages like C#.

How to use Sudo in Windows 10 Powershell

Ashraf Mehdaly — Tue, 10 Nov 2020 08:24:33 +0000

Many of us may face a small problem with windows terminal (command line) when going to execute some commands that require an admin privilege while the shell is opened in normal user privilege, so we have to restart the shell using Run As Administrator in order to proceed, whilst in Linux we simply use sudo command to execute whatever we want as a root user.
Here we have solution for this issue in Windows, just follow the following steps:
1- Using PowerShell terminal execute the following command line to install scoop package installer:

C:\>iwr -useb get.scoop.sh | iex

2- Then after installing "scoop" in your system install "sudo" package:

C:\>scoop install sudo

Now you will be able to use sudo command same as in Linux, for example in order to install npm package globally we have to run npm install in a privilege mode:

C:\>sudo npm install –g bootstrap

As well as having a sudo option in Windows, we will have the ability to install packages in Windows using "scoop" similar to apt & apt-get in Linux.
For more information how to use scoop visit :