Questions, answered.

You bring your own storage - and that one choice is what sets Nyx Backup apart. Instead of paying a monthly fee for space the vendor marks up, you connect the storage you choose - a cloud storage account, a network drive, or a plain external disk - and pay that provider directly, often just a few dollars a month. That puts you in control of cost and lets you shape backups to how you actually work: pick the provider that fits your budget, mix fast storage for quick restores with cheap archive storage for the long tail, and set each backup's schedule, retention, and storage tier independently. You are never locked into a proprietary service, never paying for capacity you do not use, and never at the mercy of a price hike on someone else's subscription.

And because your data is encrypted with a key only you hold, and stored in a fully published, open format, that control comes with no loss of safety: you own the data, and the format is documented so your data is never trapped in a proprietary black box. (More on each of these below.)

Correct. The app is a one-time purchase, and the only ongoing cost is whatever you pay your own storage provider - which you control and can change any time. See Pricing and Licensing for details.

It is built to be best-of-breed on the things that matter day to day:

• Fast. Incremental backups only touch what changed, uploads run in parallel, and restores pull data in parallel too, so routine backups are quick and out of your way.
• Light. It runs as a small background service designed for a low CPU and memory footprint and "polite" networking, so it stays invisible while you work rather than bogging down your machine or your connection.
• Comprehensive. Content-based deduplication and compression, point-in-time snapshots, flexible retention, more than a dozen storage destinations (including cold/archive tiers), locked-file handling, scheduling with battery/metered/Wi-Fi guards, pre- and post-backup commands, integrity verification, missed-backup alerts, and a partial-restore report - the capabilities you would expect from mature backup software.
• Easy. Sensible defaults and a goal-based setup wizard get you protected in minutes; the advanced controls are there when you want them, out of the way when you do not.
• Cross-platform. One product for Windows, macOS, and Linux, with a multi-machine license so your whole household or team is covered.

Because the free tools are excellent at being tools, and a tool is something you operate.

We will not pretend otherwise: programs like Kopia, restic, Borg and Duplicati are genuinely good software, they are free, and on the core engineering - deduplication, compression, strong client-side encryption - they are in the same league. If you are comfortable at a command line, enjoy reading documentation, and will happily write a scheduled task and a snapshot script, one of them is a perfectly sound choice and we would rather you used one than went unprotected.

What you are paying us for is that none of that is required. The setup wizard asks a few plain questions and picks a storage provider for you. Open and locked files are snapshotted automatically on Windows and macOS, with no flag to remember and no script to write. Restores are browsed and clicked, not reconstructed from a manual. The interface is translated into 24 languages. If a backup stops running, something tells you instead of waiting for you to notice. And when it matters most - the day you actually need your files back - there is a company on the other end of an email address, which is not something an open-source project can promise anyone.

That is the honest trade. Free software asks for your time; we ask for money once and try very hard not to ask for your time.

Completely, and before it ever leaves your computer. Your files are locked with AES-256 - the same encryption standard governments and banks use - so what lands at your storage provider is unreadable without your key. It is not just the file contents: file names and your folder structure are encrypted too, so no one can even see what you backed up or how it is organized. Nothing readable ever leaves your machine.

It means nobody but you can read your data - not Nyx Software, and not your storage provider. Your encryption key is created on your computer and stored only there, protected by your operating system; it is never sent to us or to your storage provider. Backups upload straight from your machine to storage you control, with no Nyx Software server in between. We strongly recommend keeping a copy of your key somewhere safe and offline (see the master-key questions below), because it is the one thing only you hold.

The master key is the 256-bit secret that encrypts your backups. It is generated on your computer during first-run setup, never leaves it, and is never written into a plain config file. Where exactly it is kept depends on the platform:

• Windows: the Credential Manager vault of the service account (LocalSystem), plus a machine-scoped DPAPI-encrypted copy so the service can read it at boot.
• macOS: the system Keychain (root-accessible), so the background service can load it unattended.
• Linux: this is the nuanced one. The background service runs as root under systemd and therefore has no desktop login session, so it generally cannot use the interactive keyring (GNOME Keyring / Secret Service), which is per-user and locks when that user logs out (see the next question). Instead it uses a machine-scoped store at /var/lib/nyxbackup/, automatically choosing the strongest form your system supports, in this order: 1. If your machine has a TPM (a Trusted Platform Module - a secure chip built into most modern computers) plus the small tpm2-tools package (a recommended dependency a normal install pulls in; a minimal or --no-install-recommends install may need sudo apt install tpm2-tools), the key is sealed to the TPM - bound to that physical machine, so a copy of the file is useless on any other computer. 2. Otherwise, on systemd 250+ (for example Ubuntu 24.04) it is wrapped with systemd-creds, which is also host-bound (and TPM-sealed when present). 3. Only if none of the above is available does it fall back to a plain file readable solely by root (mode 0600 in a 0700 directory).

The daemon logs which tier it used at startup, and upgrades an existing key to a stronger tier automatically (for example, sealing to the TPM the first time it runs on a machine that has one). See "How strong is the Linux root-only key file?" below for the fallback case.

At setup you are also shown a recovery phrase - a written-down form of the key - to save somewhere safe.

Because that keyring is the wrong tool for an always-on system service. The Secret Service keyring is per-user: it belongs to a specific logged-in human, lives on that user's session bus, and is unlocked only while they are logged in - it locks on logout. The Nyx Backup service, by contrast, runs as root under systemd with no human session and must start and back up unattended at boot. If its master key lived in your user keyring, backups would silently stop whenever you logged out or the machine rebooted to a login screen, and the key would sit in one user's security domain rather than the machine's. So even on a desktop where the keyring is present and working, the root service deliberately uses the machine-scoped file store instead. (Your own user-context tools, like the desktop app, can still use the keyring for their own purposes; it is specifically the unattended root service that does not.)

If your machine has a TPM (most hardware from the Windows-11 era does), the key is sealed to it automatically and stealing the file alone gets an attacker nothing - so this only concerns machines with no TPM at all (for example some cloud VMs without a virtual TPM). In that fallback case the key rests as a root-only 0600 file, and it is worth being clear-eyed about what that does and does not protect:

• It does stop other (non-root) local users from reading the key.
• It does not meaningfully stop an attacker who already has root on the running machine - at that point they could also read the key straight out of the service's memory, so no at-rest scheme helps much. This is true of every backup tool, not just this one.
• Its real weak spot is offline theft of the disk or VM image, because the key is stored in the clear.

The fix for that weak spot on a TPM-less machine is full-disk or volume encryption (LUKS) on the partition holding /var/lib/nyxbackup, which is the standard practice for protecting secrets at rest on a server and closes the stolen-disk gap completely. (LUKS can itself be auto-unlocked by a TPM, so it stays fully unattended.) App-level "encrypt the file with another key stored right next to it" would be security theater, so we do not pretend to offer it; a TPM or LUKS is the honest answer. The daemon logs a clear warning at startup when it detects neither a TPM nor an encrypted volume.

Then your backups cannot be recovered - unless you saved a copy of the key somewhere off the computer. This is the flip side of zero-knowledge encryption: because we never have your key, no one (including us) can unlock your data without it, and there is no reset link or backdoor. That is exactly what keeps your data private, and exactly why you must keep a copy of the master key (or the recovery phrase shown at setup) somewhere separate and secure: a password manager, a printed copy in a safe, or both. If your computer dies but you have that copy, you get everything back.

Two ways, and either is enough. At first-run setup the app shows you a recovery phrase and asks you to confirm you have written it down - that phrase reproduces your key. After that, or at any time, the command-line tool writes the key to a file:

nyx_bkp_cli export-key

With no arguments that writes nyxbackup-master.key into your Documents folder. Pass --output to choose somewhere else - a file path, or a folder to drop the default filename into:

nyx_bkp_cli export-key --output D:\keys\nyxbackup-master.key

The file is small and plain text: a few comment lines and the key itself. Treat it exactly as you would the password to everything it protects - anyone holding it can read your backups. Your computer shows a notification whenever the key is read, so an export you did not start is something you find out about.

Then put it in at least two separate places, and not on the computer being backed up: a password manager, a printed copy in a safe or a safe deposit box, an encrypted USB drive kept somewhere else. The one arrangement that does not work is leaving the only copy on the machine whose failure you are insuring against.

This file is also what the free Nyx Backup Recovery tool asks for when you are restoring on a computer that cannot run the main app.

If you own and administer all of them - a household, or a business where one person is responsible for the machines - then yes, use one key everywhere. The likeliest way to lose a backup is not an attacker; it is nobody being able to find the key years later, when it is finally needed. Every additional key is another thing to store, label, and eventually misplace. One key also means any surviving machine can restore any other machine's backups.

Use separate keys when the machines belong to different people. A shared key means anyone who can extract it from their own computer can decrypt everyone else's backups, so staff laptops, client machines, or anything you do not administer should each hold their own. The dividing line is trust, not the number of computers.

Two things worth knowing before you decide:

• It is a setup-time choice. A machine that already has a key will refuse to replace it, so sharing a key means importing it during first-run setup on the second machine. Changing your mind later means clearing that machine's stored key, and any backups it already made remain tied to the key that made them.
• It makes no difference to your storage bill. Each machine's data is stored under its own namespace, so two machines never share or de-duplicate each other's data whether the key is shared or not. The decision is purely about how many keys you have to keep safe, and how much a single leaked one would expose.

This is unrelated to your license: seats count machines, and have nothing to do with how many encryption keys you use.

AES-256-GCM for data, SHA-256 and HMAC-SHA256 for hashing and content-addressing, HKDF-SHA256 to derive purpose-bound per-set subkeys, and Ed25519 for signing license files. The master key can be derived from a passphrase using Argon2id (default) or PBKDF2-HMAC-SHA256. The master key is never used directly - separate subkeys are derived per backup set and per purpose.

Yes. Rather than ship its own crypto, Nyx Backup routes every core operation (AES-256-GCM encryption, SHA-256 hashing, HKDF, HMAC-SHA256, Ed25519 signatures, and the optional PBKDF2 key derivation) through the cryptographic module that each operating system's own vendor has put through FIPS 140 validation:

• Windows: Microsoft's Cryptography API: Next Generation (CNG), covered by Microsoft's per-Windows-version FIPS 140-2 certificates.
• macOS: Apple's CoreCrypto, covered by Apple's per-macOS-version FIPS 140-2 certificates.
• Linux: Amazon's AWS-LC, whose FIPS build carries FIPS 140-3 Certificate #4759; every released Linux build links that validated module.

(The standard version differs by platform: Windows and macOS ride their vendor's 140-2 modules, Linux is 140-3 via AWS-LC.)

So the algorithms are not a home-grown implementation - they are the same validated code trusted in regulated government and enterprise environments. The one deliberate exception is Argon2id, our default password-to-key function: no vendor's FIPS module exposes Argon2id yet, so it uses a well-reviewed standalone implementation (RFC 9106). It is not (yet) on the FIPS-approved list, but it won the Password Hashing Competition and resists modern password-cracking hardware far better than the older PBKDF2. If you must keep every step inside the validated boundary, you can switch key derivation to PBKDF2, which runs inside the OS module above. To be precise: this is FIPS-grade validated componentry, not a completed FIPS 140-3 validation of the Nyx Backup application as a whole.

Good cryptography is as much about handling keys correctly as about picking strong algorithms, so a few deliberate practices back the ones above:

• Keys are separated by purpose. Your one master key is never used to encrypt anything directly. Instead, HKDF-SHA256 derives a distinct subkey for each backup set and each purpose (one subkey for file-chunk encryption, a different one for manifest encryption). A problem with one subkey cannot expose another set or another purpose.
• Keys are wiped from memory after use. The master key and every derived subkey are zeroized (overwritten in RAM) the moment they are dropped, so they do not linger in memory longer than needed.
• Keys are locked into physical memory. The master key and every subkey are held in memory pages the operating system is told not to swap out, so they are not written to the page file while the service runs.
• The master key is not kept in memory between jobs. It is read from the secure store only for as long as an operation needs it, and a backup run itself holds only the derived subkeys for that one backup set - not the master key everything else depends on.
• Keys and credentials are kept out of the config file. The master key and your storage credentials go to the operating system's protected credential store (Windows Credential Manager, macOS Keychain, or the Linux keyring) wherever the running process can reach one; the config file only ever holds a non-secret reference. Where a background system service has no credential store available to it (common on headless Linux - see the master-key storage question), they fall back to a machine-scoped file that is host- or TPM-bound where the OS supports it, and otherwise restricted to the service account, with disk encryption as the recommended at-rest protection.
• Each backup set is cryptographically partitioned. Because every set has its own subkeys, one storage destination can safely hold backups from several sets or several machines without them being able to read one another.
• Every stored object is authenticated. Data is sealed with AES-256-GCM, an authenticated cipher, so any tampering with the ciphertext is detected on restore rather than silently decrypted into corrupt files.
• Passphrases are normalized before hashing. Passphrases are Unicode NFC-normalized (per NIST SP 800-132) so a passphrase typed with visually identical but byte-different characters still derives the same key.
• Only one crate touches raw cryptography. All primitives are confined to a single audited module that routes to the OS vendor's validated backend; no other part of the app reaches for a crypto primitive directly.

Both turn your passphrase into a key, but they resist attackers differently. PBKDF2 is CPU-only, so an attacker with cheap parallel hardware (GPUs, FPGAs, ASICs) can guess passphrases extremely fast. Argon2id is memory-hard: it deliberately requires a large amount of RAM per guess (our default is 128 MiB, with 3 passes and 4 lanes), which is exactly the resource that mass-parallel cracking rigs find expensive to scale. Argon2id won the Password Hashing Competition, is specified in RFC 9106, and is OWASP's recommended password KDF, so it is the stronger default for protecting your master key.

The one tradeoff is FIPS status: Argon2id is not yet FIPS-approved (it is not in NIST SP 800-132 Rev 1, though it is under consideration for Rev 2), whereas PBKDF2 runs entirely inside the OS vendor's FIPS-validated module. So the choice is offered: Argon2id for the strongest real-world resistance (the default), or PBKDF2-HMAC-SHA256 (1,000,000 iterations, well above OWASP guidance) when you must keep every step inside the validated boundary. The choice is fixed at setup, because changing it later would invalidate the key that every existing backup was encrypted with.

Not to anyone outside your machine, because Nyx Backup switches the operating system's crash reporting off for its own programs.

That matters more than it sounds. By default, when a program crashes, Windows can send a memory snapshot to Microsoft, Ubuntu can offer to send one to Canonical, and macOS can send one to Apple - and on Linux a copy is written to disk where it sits until something cleans it up. A backup program's memory is a bad thing to have travelling: it briefly holds encryption keys, and during a backup it holds pieces of your files.

So the service and its companion programs opt out at startup, on all three systems, and nothing about your crash is uploaded or left lying around. We also do not collect crash reports of our own - there is no telemetry that sends memory contents anywhere, by deliberate design.

Two honest limits. If your computer hibernates, the system writes all of memory to disk, and no program can opt out of that - full-disk encryption (BitLocker, FileVault, LUKS) is what protects that file, which is one of the reasons we recommend it. And someone who already has administrator access to your running computer can read the memory of any program directly; at that point no backup tool can protect you, and one claiming otherwise is not being straight with you.

No. Backups belong to the account that set them up.

The background service only accepts instructions from that account. If somebody else signs in to the same computer - even as a second everyday user - the app will tell them the backups belong to another user rather than letting them browse your snapshots, start a restore, change your settings or export your encryption key. On Windows and Linux we go further and lock the service's private communication channel to your account, so another user's software cannot even open a connection to it.

An administrator of the computer is a different matter. Administrators can read any file and any program's memory, so they can reach your backups regardless of what any application does. If you do not want the machine's administrator to be able to read your files, the protection you need is a separate computer or a separate encrypted disk, not a setting in a backup program.

No. We do not hold your key, and your data never passes through our servers - it goes straight from your machine to the storage backend you control. A legal demand to us could not produce your decrypted files, because we do not have them and cannot decrypt them. The only party who holds both your storage and your key is you.

Your backups and restores only ever talk to the storage you configure - never to us. Your license file also proves itself entirely on your machine: the app verifies its digital signature locally, so no server is needed to confirm it is genuine and the app keeps working offline. There is one light exception: when your machine is online, the app periodically checks in with the license server for a single purpose - to count how many machines are using your license and enforce your seat limit. That check sends no file data, and if you are offline it is simply skipped; your backups and restores never depend on reaching us. The other optional signal is anonymous usage telemetry (see the next question), which never contains file names, paths, contents, credentials, hostnames, bucket names, or error text.

It exists so we can understand overall usage patterns and error trends and use that to improve the product - nothing more. It is on by default and can be turned off in Settings or the config file, which stops all sends immediately. When on, it sends at most once every ~30 days: a pseudonymous install ID (an HMAC of the machine ID, never your license key, hostname, or hardware serial), the app version, OS family and CPU architecture, license state, counts of backup sets/snapshots/bytes by storage type, run and restore success/failure counts, and a category code for the most common error. It never sends file names, paths, contents, storage URLs/buckets, credentials, hostnames, or free-text error messages.

Your storage access keys, secrets, and cloud sign-in tokens are sensitive, and they are treated that way: they are never kept in the plain settings file. Wherever the running process can reach the operating system's protected credential store (the same place your master key lives), that is where they go. Where a background system service has no credential store available to it - most often a headless Linux server, where the desktop keyring is per-user and the root service has no session - they are stored in a machine-scoped file restricted to the service account, host- or TPM-bound on systems that support it. On a server, protect that at rest the same way you protect the master key: full-disk or volume encryption (LUKS). See "How strong is the Linux root-only key file, and can I harden it?" above for the details.

One deliberate, benign change on Windows: the installer adds Microsoft Defender process exclusions for Nyx Backup's own executables (the service, GUI, command-line, terminal, and toast helper). Defender otherwise re-scans the app's long-running upload and download activity, which can slow backups significantly, so excluding its own processes is standard for backup software. It is done automatically at install (which is why you never see a prompt), it is logged, and it is removed when you uninstall. If you have Defender Tamper Protection turned on, Windows blocks the automatic add - the app's Settings screen shows whether the exclusions are active, so you can add them by hand if needed. The one-line command (run in an admin PowerShell) is:

Add-MpPreference -ExclusionProcess 'nyx_bkp_service.exe','nyx_bkp_gui.exe','nyx_bkp_cli.exe','nyx_bkp_tui.exe','nyx_bkp_toast.exe'

Beyond that, Nyx Backup does not add firewall rules and does not change your network or proxy settings; its "polite" low-priority networking is applied per connection while a backup runs, not as a persistent system setting. A normal install also registers the background Windows service and creates the app's own folders under ProgramData - that is the extent of what it touches.

Yes. First, a bit of background: to save space and money, Nyx Backup splits your files into small pieces called "chunks" and keeps a "manifest" - an encrypted table of contents that records which chunks make up each file in a backup. Both the chunks and the manifests are protected with a cryptographic seal. If anything in your stored backup were altered, swapped, or corrupted - by a faulty disk, a bad actor, or a storage bug - that seal would not match, and the app refuses to trust the changed data rather than restoring something wrong. Critical bookkeeping is also kept as a second backup copy for extra resilience.

A backup set is one named, self-contained backup job. It bundles everything that job needs: which files and folders to protect, the storage destination and its sign-in credentials, the schedule, how long to keep old versions (retention), and what to exclude. You can create several backup sets, each pointing at its own destination with its own settings - for example one set of documents to Backblaze B2 and a separate set of photos to a local drive.

A snapshot is one point-in-time backup of a set. Each run that finds changes produces a new snapshot. Snapshots are incremental and deduplicated, so a snapshot only stores data that is new relative to what is already in the destination, while still letting you restore the full state as of that moment.

Files are split into variable-size pieces based on their content, and each piece is identified by a secure fingerprint of what it contains. If the same piece appears in more than one file, or is unchanged between backups, it is stored only once - so repeated and unchanged data does not cost you storage twice. The pieces are compressed and then encrypted before upload.

On a timed schedule you can run a set as often as hourly, or daily or weekly, and you can start any set on demand at any time with "Back up now." The current release does not have an always-on, save-triggered mode that uploads the instant a file changes - hourly is the most frequent automatic option. Because backups are incremental, an hourly run is quick and only moves what changed.

Normal backups are incremental: only new or modified files are re-read and uploaded, and unchanged files are skipped, which is what makes routine backups fast. To find what changed, the app compares each file's recorded size, timestamp, and content fingerprint against what it backed up last time. As a safety net against anything a quick metadata check could miss, the app also performs a periodic FULL re-scan on its own - by default about once a week - that ignores the change list and re-reads every file in the set to confirm nothing was left behind. You can change how often that full pass runs, and you can trigger a full re-scan yourself at any time. Thanks to deduplication, these full passes still only upload data that has actually changed.

Yes, with two sensible exceptions. A background service runs continuously and executes each set on its schedule, so once a set is configured you do not have to remember to run it. The exceptions: a set on the "manual" schedule is never started automatically - it runs only when you tell it to

• and a set you have disabled is skipped entirely until you re-enable it.

Either way, you can always start any set on demand ("Back up now") whenever you want, regardless of its schedule. On Windows the service is a Windows service (NyxBackupSvc / "Nyx Backup Service"); on macOS a launchd daemon; on Linux a systemd service. The desktop app, the command-line tool, and the text-based (terminal) interface are all lightweight front-ends that talk to it.

It means whether the app is connected to that background service - not whether you are connected to the internet. "Online" simply means the desktop app can talk to the service that does the actual backing up; "Offline" means it cannot reach it right now (for example, the service is starting up, stopped, or briefly busy). Your backups are run by the service itself, so a momentary "Offline" in the app does not mean a backup was missed. See the troubleshooting section if it stays offline.

Automatically on Windows and macOS, and on Linux when your files are on Btrfs, with nothing for you to turn on.

This matters more than it sounds. Your mail database, your accounting file, a database a program keeps open - the operating system locks these while they are in use, so a backup that simply reads files will either skip them or, worse, copy them half-written. The fix is to snapshot the entire volume first and back up that frozen copy, so every file is captured exactly as it looked at one instant.

On Windows the app uses VSS (Volume Shadow Copy) to read locked files consistently. Nyx Backup requests a persistent shadow copy, which means it survives a reboot: if a large first backup is interrupted, it resumes rather than starting over. On macOS it takes a real APFS snapshot of the Data volume (via tmutil localsnapshot plus mount_apfs), which needs root and Full Disk Access. On Linux, if the files you are backing up sit on Btrfs, it takes a read-only subvolume snapshot and backs that up, then deletes it when the run finishes - the same guarantee as Windows and macOS, and you do not have to enable anything. On any other Linux filesystem it reads files directly with O_NOATIME, because there is no snapshot facility available to take. ZFS is recognised but not yet snapshotted, and LVM snapshots are deliberately not used: they need free space set aside in advance that most installs do not have, and they fail in ways that are easy to miss. If a file still cannot be read, that one file is logged and skipped without stopping the rest of the run.

This is worth checking when you compare tools. Several well-regarded backup programs either require you to pass a flag to get snapshots, ship with them switched off, support them on Windows but not macOS, or expect you to write your own scripts to create the shadow copy. A snapshot you have to remember to enable is one you will eventually forget.

Very little - efficiency was a core design goal. Nyx Backup is written in Rust and compiles to native code, so it carries no heavy runtime, virtual machine, or garbage collector the way tools built on C#, Java, or Go do. The practical result is a genuinely tiny footprint: on Windows the idle background service has been observed using only a few megabytes of RAM (single digits), where a comparable service on a runtime-based stack often sits at tens or hundreds of megabytes. During a backup it keeps CPU use modest and adapts automatically to your machine's available memory and processor. On Windows it also goes further than most backup software in staying out of your way: the threads that read and hash your files run below the priority of whatever you are doing, and the service samples how busy the rest of the machine is every ten seconds, easing off while you are working and taking the speed back when you stop. The result is that a large backup can run while you use the computer without the pointer stuttering or typing lagging. Uploads are "polite" by default, using low-priority networking so a backup does not saturate your connection, and you can set an upload speed cap, including one that changes automatically at set hours.

Yes, and you get it automatically. The heavy per-byte work in a backup is encryption and hashing, and Nyx Backup performs both through your operating system's own cryptographic module (CNG on Windows, CoreCrypto on macOS, AWS-LC on Linux). Those modules use your CPU's built-in cryptographic instructions wherever the chip provides them - AES-NI and the SHA extensions on modern Intel/AMD processors, and the ARMv8 Cryptography Extensions on Apple Silicon and other ARM chips - so AES-256-GCM encryption and SHA-256 hashing run several times faster and at much lower CPU cost than a pure-software implementation. Compression is likewise handled by zstd, which uses SIMD-optimized routines. The net effect is faster backups that use less of your processor, with nothing for you to configure; on the rare CPU without these instructions it simply falls back to a correct software path.

That is exactly what the "polite" networking is for: the app marks its uploads as low-priority so that interactive traffic like video calls, streaming, and games takes precedence, and a backup yields the bandwidth. One caveat: this automatic yielding relies on your operating system (and in some cases your network/router) supporting low-priority traffic; where that support is not present, the effect is weaker. If you ever notice a backup competing with other activity, you can also schedule backups or throttle bandwidth to specific hours.

Hooks let a backup set run your own script before and/or after it backs up, each with a configurable timeout. A non-zero exit from the pre-hook aborts the run (so a failed database dump never produces an incomplete backup); a non-zero exit from the post-hook is logged as a warning but does not fail the committed backup. Everything the script prints is captured to the service log. Typical uses: dump a database to a file so the backup captures a clean copy, quiesce or pause an app for a consistent snapshot, unmount a volume afterward, or send a notification when a run finishes or fails.

You do not have to write these from scratch. Nyx Backup ships a library of ready-made example scripts and drops them into an examples folder inside the hooks directory (%ProgramData%\NyxBackup\hooks\examples on Windows, /Library/Application Support/NyxBackup/hooks/examples on macOS, /etc/nyxbackup/hooks/examples on Linux; refreshed on each update). The library covers database dumps (MySQL, PostgreSQL, MongoDB, SQLite), quiescing an application, and notifications (email via API or SMTP, SMS, and generic webhook). To use one, copy it up one level into the hooks directory, edit it to fill in your details (server, database name, email address, and so on), then select it as the set's pre- or post-hook. For safety the hooks directory is admin-only and the app runs only a script placed directly in it and chosen on a set - the examples copies themselves are inert templates and never run on their own.

Yes. Besides the desktop app there is a text-based interface that runs inside a terminal (works great over SSH on a machine with no monitor) and a command-line tool for scripting and automation. The first-run setup that creates your master key is available in the desktop app and the text-based interface.

Amazon S3, generic S3-compatible providers, Wasabi (S3), Backblaze B2 (both native B2 and B2's S3-compatible mode), Azure Blob Storage, Google Cloud Storage (HMAC keys or service-account JSON), SFTP, SMB/network shares, WebDAV, local or attached disk, plus Google Drive, Dropbox, and Microsoft OneDrive via one-click OAuth.

No - there is no Nyx Software cloud, and that is on purpose. You bring your own storage: a cloud storage account (the space you rent is usually called a "bucket"), a network drive, or even a plain external disk. You pay the storage provider directly - often just a few dollars a month, and far cheaper than most "backup service" subscriptions because you are buying raw storage instead of a markup. It also means your data is never locked inside a proprietary service: you own the account, you hold the key, and you can walk away or switch providers whenever you like.

Any service that implements the S3 API. What Nyx Backup needs from one is multipart upload, ranged downloads, and an existence check on an object.

Amazon S3, Cloudflare R2, Backblaze B2 and Wasabi are recognised by name, so the region is worked out for you and the app labels the set with the provider. Beyond those, self-hosted and NAS services (MinIO, Ceph, Garage, SeaweedFS, TrueNAS, Synology, QNAP), hosting providers (DigitalOcean Spaces, Linode/Akamai, Vultr, Hetzner, OVHcloud, Scaleway, Exoscale, UpCloud, Contabo), the larger clouds (IBM, Oracle OCI, Alibaba OSS, Tencent COS) and others (iDrive e2, Storj, Filebase) all speak it. Those are not individually tested here, but nothing about them is unusual, and Test connection tells you before you save a set.

Two exceptions: Google Cloud Storage and Azure Blob Storage each have their own connector, so use those rather than routing them through S3. Azure has no S3 interface of its own at all. The full list is on the S3-compatible setup page.

It depends on your budget and how often you expect to restore. A few rules of thumb (provider prices change, so check current rates):

• Backblaze B2 is usually the cheapest per gigabyte, which suits large backups you rarely restore. (B2 is raw storage, not Backblaze's own single-PC "Personal Backup" app - use it here and you keep full control and can point every machine at it.)
• Some S3-compatible providers charge no egress fees at all, which is attractive if you restore often or read from several machines - with the trade that transfers from such a provider can be slower over a home connection (see the next question).
• Amazon S3 is the fastest and most universally supported, but it charges for data pulled back out on a restore.
• Google Drive, Dropbox, or OneDrive can be the most economical option if you already pay for one and have unused space sitting there - no new account or bill required.

You are not locked in - you can move a set to a different provider later.

They can be, from a home connection. Free-egress pricing is a genuine advantage, but with some providers large downloads over residential internet occasionally stall mid-stream, so Nyx Backup automatically downloads from those providers in smaller pieces and limits how many run at once to keep transfers reliable. The net effect is that a big restore from a free-egress provider can be slower than from a top-tier one like Amazon S3 - the payoff being that you pay nothing to pull your data back.

Yes, for many people it is a solid all-rounder. Wasabi is S3-compatible, priced close to Backblaze B2 (a little more in some cases), and does not charge egress fees. The main catch is a 90-day minimum storage charge per object, so it is best for backups you keep for a while rather than sets with heavy day-to-day churn.

Yes, safely. Every object is namespaced by machine ID and set ID (packs/<machine-id>/<backup-set-id>/...), so machines and sets never collide and one machine's cleanup can never delete another's data. When you point a set at a destination that already holds other data, the app detects it and shows an informational, non-blocking notice.

You click "Connect," authorize in your browser, and the app stores a refresh token in your OS credential store. These use narrow, app-scoped access: Google Drive uses the hidden app-data folder (drive.appdata), Dropbox uses App-folder access sandboxed to /Apps/Nyx Backup/, and OneDrive uses a public PKCE client. The app only ever sees its own folder, not your personal files.

Google Drive stores Nyx Backup's data in a special hidden "app data" area that keeps it out of your normal Drive view (so it never clutters My Drive and you cannot accidentally move or delete individual pieces). Because it is hidden, you will not find it by browsing Drive - but you can remove it in two supported ways:

• From inside Nyx Backup (recommended): delete the backup set that targets Google Drive. Deleting a set removes that set's stored data from the destination, cleanly and through the same connection that wrote it.
• From Google Drive on the web: open Settings (the gear icon) -> Settings -> Manage apps, find Nyx Backup in the list, open its Options menu, and choose "Delete hidden app data." This wipes everything the app has stored in that hidden area in one step.

Note that simply revoking the app's access (in your Google Account's "Third-party apps" settings) stops future access but does not by itself delete the already-stored data - use one of the two methods above to remove it.

Dropbox and OneDrive both keep a real folder that their desktop app syncs to every computer signed into that account - so your encrypted backup folder can get re-downloaded onto your other machines, using up disk space. The fix is per device: on Dropbox, use Selective Sync to exclude the Apps/Nyx Backup folder; on OneDrive, either mark the NyxBackup folder as online-only (Free up space) or exclude it from that PC's sync. On Dropbox, never use "Ignore" (.dropboxignore / com.dropbox.ignored) for this - Ignore deletes the cloud copy, which is your backup. There is no way to automate this, so it is a manual step on each computer. If you would rather avoid it entirely, Google Drive is immune (Nyx Backup uses Google's hidden app-data area, which the desktop app never syncs down), and object-storage providers like Backblaze B2 have no sync client at all.

Yes - this is an advanced option most people never need. You can point the Google Drive, Dropbox, or OneDrive connection at your own registered developer app instead of the one built into Nyx Backup. It exists purely for continuity and control: your cloud backups keep working even in the unlikely event a built-in app is ever disabled, and organizations can use their own app registration.

Nyx Backup resolves each credential in this order: an environment variable first, then an oauth.toml override file, then the built-in default. The names are:

• Google Drive: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET
• Dropbox: DROPBOX_APP_KEY, DROPBOX_APP_SECRET
• OneDrive: ONEDRIVE_OAUTH_CLIENT_ID (a public client - no secret)

The oauth.toml file is usually the easier route than setting service environment variables. It is plain TOML with lowercase keys, for example:

google_client_id = "your-id.apps.googleusercontent.com"
google_client_secret = "your-secret"
dropbox_app_key = "your-key"
dropbox_app_secret = "your-secret"
onedrive_client_id = "your-app-id"

Put it in the app's config directory - on Windows %ProgramData%\NyxBackup\oauth.toml (or per-user %APPDATA%\NyxBackup\), on macOS /Library/Application Support/NyxBackup/oauth.toml (or the per-user Library path), on Linux /etc/nyxbackup/oauth.toml (or ~/.config/nyxbackup/oauth.toml). After adding it, restart the service and re-connect the endpoint so a fresh token is issued against your app. A full operator walkthrough ships with the product (OAUTH_BYO).

Yes - create two backup sets over the same files, each pointing at a different destination. For example one to a local NAS for fast restores and one to Backblaze B2 for off-site safety, which is exactly the classic 3-2-1 arrangement (an on-site copy plus an off-site copy).

Each set keeps its own schedule, retention policy and history, so you can back up to the fast local copy hourly and to the cloud nightly, and a problem with one destination never affects the other. That independence is the reason we do not fold this into a single set: one set writing to two places at once has to answer awkward questions - what a "successful" run means when one destination failed, which copy a restore reads from, what happens when a destination is unreachable for a week - and two ordinary sets answer all of them by construction, and are far easier to reason about when something does go wrong.

Yes, where the provider offers them - S3 Glacier and Glacier Deep Archive, Azure Archive/Cool, and Google Cloud Storage classes. You pick a tier for a set, and the editor can move already-uploaded data to a colder tier in place on backends that support it. Cold tiers are very inexpensive to store, with two trade-offs to know about: restoring first requires a "warm-up" that can take hours before the data is downloadable (the app starts this for you automatically and waits), and because the data is not readily accessible, routine integrity checks are limited while it sits cold. Cold storage is best for archives you are keeping just in case, not for backups you expect to restore on short notice.

Under a small set of prefixes: machines/, indexes/, manifests/, sets/, and packs/. Packs (the encrypted chunk data) live at packs/<machine-id>/<backup-set-id>/<pack-id>.pack. The full layout is public in the format specification at nyxbackup.com/format.

Three editions by machine count: Solo (1 machine) at $39.99, Home (3 machines) at $69.99, and Pro (5 machines) at $99.99. Each is a one-time purchase that includes 12 months of free updates.

No. The app license is a one-time, perpetual-use purchase - buy it once and it keeps working forever. What is time-limited is only the update window: your purchase includes 12 months of free updates, and you can optionally buy another 12 months of updates later (see maintenance). If you never buy more, the app you already have keeps running indefinitely; you simply stop receiving new versions.

Maintenance is an optional "another year of updates." You do not have to buy it, and there is no auto-renew or recurring charge - the app you own keeps working without it. When your update window is ending, the app simply lets you know, and you can choose to buy another year if you want the newer versions. See the pricing page for current maintenance pricing.

Backups keep running normally. The only thing your update window controls is which app versions your license covers: any build released within your paid window is yours to run forever. You can uninstall and reinstall freely - reinstalling a version you were already entitled to just works. If you install a build released after your window lapsed, the app still runs and still restores, but it flags that those newer updates are outside your window until you buy another year. Restores are never affected either way.

Yes, a 60-day free trial with full functionality and no credit card required to start. When the trial ends, new backups stop, but you can still browse snapshots, run restores, and verify integrity - getting your data back is never gated.

Never. Restoring, browsing snapshots, and integrity checks are never gated by license state - by design. Only new backups are gated when a trial expires or a license is invalid. A backup product that held your data hostage would defeat its own purpose.

Mostly offline. You receive a small Ed25519-signed .lic file by email after purchase and import it into the app, and the app verifies its signature entirely on your machine against a trust key built into the binary - so proving your license is genuine never needs a server, and the app does not stop working if our server is unreachable. The only online part is seat counting: when your machine has a connection, it registers against your license's seat ledger so the per-edition machine limit can be enforced. That is opportunistic and offline-tolerant - it never blocks a backup or restore because of a network problem, only because you are genuinely over your seat count.

Seats are the number of machines your edition covers (Solo 1, Home 3, Pro 5). Each machine checks in with the license server when it is online and registers against your license's seat count. If you go over your limit, new backups on the machine that puts you over are paused until you free a seat - you can deactivate a machine you no longer use from Settings. Two things always hold: restores are never gated by seats, and a machine with no connectivity is never blocked (seat counting only happens online, and a fully offline/air-gapped machine runs on the license file alone).

Import the same .lic file on the new machine. There is no hard device-lock, so moving or reinstalling is mainly a matter of keeping your .lic file (and your master key). If you are at your seat limit, first deactivate the old machine (Settings) to free a seat for the new one. Keep both the license file and your master key with your important records.

Payments run through Paddle as Merchant of Record, so Paddle handles the checkout and any sales tax/VAT for your country. Through Paddle you can pay by credit/debit card, PayPal, Apple Pay, or Google Pay (available methods vary by region). After purchase, Nyx Software's own licensing service issues your signed license and emails it to you. Nyx Software never sees your card details.

Open the Snapshot browser, pick a backup set and a snapshot, select the files or folders you want, and choose a destination. The app downloads and decrypts the needed pieces in parallel and reconstructs your files. If you are not sure which snapshot a file is in, use the Search view to find it by name or pattern across every snapshot (see "Can I search across all my snapshots for a file?" below) and restore straight from a result.

By default restores go to a dated folder on your Desktop, or you can pick any local directory. Restoring directly in place over the originals is not supported - restores always land in a chosen destination folder so they never overwrite live data unexpectedly. After a restore the app can open the destination folder for you.

Restores are per-file and produce a report. The completion screen shows how many files restored, failed, or were skipped, with per-file reasons and remedy hints, and the failure ledger can be exported. Files that need a missing pack are reported as "skipped" distinctly from real errors, so you can tell a transient problem from missing data.

Skip (the default - do not touch existing files), Overwrite, and Rename (write the restored copy under a new name). This lets you pull back a single lost file without disturbing everything else in the target folder.

Yes. Restores checkpoint completed files, so if the service stops or the machine reboots, the restore resumes automatically and skips files already written. Only one restore per set runs at a time, and a paused restore's progress is preserved. Interrupted-restore checkpoints are cleaned up after 7 days.

The app detects packs that sit in a cold/archive tier, notifies you, and initiates the retrieval (thaw) with the provider. It then polls the retrieval status - across service restarts if needed - and proceeds with the restore once the data is warm. Because archive retrieval can carry a cost and a delay, the app surfaces that up front rather than silently blocking.

Yes, optionally. You can set a restore password that gates the restore UI as a second check against someone at your machine pulling data. It is stored as a one-way hash in the local database (not in the keychain), and it can be set, changed, or cleared. For unattended/headless restores the password can be supplied via a file, an environment variable, or stdin.

Yes, and forgetting it never risks your data: the restore password is only a local gate on the restore screen, not part of your encryption. Your backups are still protected by your master key. If you remember the password, just change or clear it in Settings. If you have truly forgotten it, an administrator on the machine can clear it, because the one-way hash lives in the app's local database (state.db), in a system folder only an admin/root user can reach:

• Windows: C:\ProgramData\NyxBackup\state.db
• macOS: /Library/Application Support/NyxBackup/state.db
• Linux: /var/lib/nyxbackup/state.db

Stop the Nyx Backup service first so the database is not in use, then remove the stored hash with any SQLite tool:

DELETE FROM app_settings WHERE key = 'restore_password_hash';

Start the service again; the restore screen no longer asks for a password and you can set a new one in Settings. Editing config.toml does not help - the hash is in the database, not the TOML file. Because that folder is admin/root only, a casual snooper on your unlocked session cannot do this (the gate still keeps them out), but you, as the machine's owner, are never locked out of your own restores.

Yes. Nothing removes snapshots on a schedule or in the background. Retention is only ever evaluated at the end of a backup that actually ran, or when you run a cleanup yourself from the app - so a set that has not backed up for six months has had nothing evaluated and nothing deleted.

Two further safeguards apply even when backups are running. Automatic deletion is off unless you turn it on: by default the app lists what retention would remove and waits for you to approve it. And the most recent snapshot of a set is never deletable, whatever the policy says.

Restoring is not affected by your licence. If a trial or licence lapses while you are away, new backups pause, but browsing and restoring every snapshot you already have keeps working - in the app and in the free Recovery Tool.

Three things worth knowing, because they are outside the app's control:

• Rules you set at your storage provider still run. If you added a lifecycle rule that expires objects after N days, it does that on the provider's schedule regardless of what Nyx Backup does.
• Archive tiers still need thawing. Data in Glacier-class storage stays put, but a restore has to wait for retrieval and may incur the provider's minimum-storage-duration charge.
• The storage account has to still exist. An unpaid bill or an inactivity suspension at the provider is between you and them, and a long quiet period is exactly when that happens.

The thing most likely to go wrong after a long gap is not the data - it is the key. Restoring on a rebuilt or different machine needs your master key or recovery passphrase. If you have been away from this for months, check you can still find it before you need it.

No - by design, your ability to get your data back does not depend on us at all. Your data is encrypted with a key only you hold, it lives in storage you control, and the entire on-disk format is publicly documented at nyxbackup.com/format - so a reader for your archives can be built from the published spec alone, by anyone, forever. You are never locked into a proprietary format that only our software can open. Even if Nyx Software disappeared, your encrypted data plus your master key is enough to get everything back.

Yes. You can search across snapshots by exact name or glob pattern and filter by date range, size, and set name, then restore straight from a result. Note that regular-expression search is not available in the current release - substring and glob matching only.

Yes. Sets can run scheduled integrity checks that re-download and verify a sample of chunks, and there is a lighter HEAD-only audit that compares each pack's cloud-side hash to its upload-time baseline. Once a set's restorability is verified, the dashboard shows a "restore-verified" trust badge.

Yes, and on self-hosted destinations it repairs the damage automatically. For backups written to a NAS or self-hosted server (SMB, SFTP, WebDAV), Nyx adds Reed-Solomon erasure-coding "parity" next to each data pack. If part of a pack later goes bad on disk - bit rot, a bad sector, a partial write - the parity lets Nyx rebuild the damaged pieces: a restore repairs the pack on the fly, and the scheduled integrity check heals it in place and reports what it fixed. Cloud object stores (Amazon S3, Backblaze B2, Azure, Google Cloud, Dropbox, and the like) already keep multiple internal copies, so parity is off there by default rather than paying for redundancy you already have; it is never added for cloud or a plain local disk. Where it is enabled, parity costs roughly 20% extra space.

Yes, at two levels. First, the backup format itself is write-once: every pack and manifest is content-addressed and only ever added, never overwritten or edited in place, so a backup run only appends new objects. That means ransomware encrypting the live files on your machine simply produces a new snapshot - the earlier snapshots and their data are left untouched and still restore cleanly, exactly as they were before the attack.

The harder risk to any backup is different: someone (or something) using your storage credentials to delete or overwrite the stored objects directly. For that, Nyx can turn on your storage provider's own object-lock / versioning, so deletions and overwrites are retained and reversible for a retention window you choose - a hidden or replaced object can be rolled back instead of lost. And because the per-snapshot index is the only piece Nyx ever rewrites, even if that index were deleted or corrupted the whole backup history can be rebuilt from the write-once manifests, so your snapshots stay recoverable either way.

Yes. Day to day you restore right inside the app, but even in the worst case - the machine running Nyx Backup is gone entirely - your data is still fully recoverable on a brand-new computer. To do it you need two things: your master key (or the recovery phrase shown at setup), and your storage account's own login/credentials so you can reach the bucket or folder your backups live in. With those, you install Nyx Backup on the new machine, reconnect the same storage, and restore. Because the on-disk format is precisely documented, recovery never depends on your original machine.

Important: keep BOTH of these somewhere safe and separate from the computer being backed up - a password manager or a printed copy in a secure place. Your master key protects the encryption; your storage credentials get you back into the storage itself. Losing the master key means the data cannot be decrypted; losing the storage login means you (or your provider) have to recover that account before you can even download the backup.

For the technically inclined there is also a separate, advanced recovery utility built for exactly this scenario; most people never need it and it is not required to get your data back, so it stays out of the way of everyday use.

It depends on where your backups are stored, and it is worth knowing before you need it rather than during.

Restorable from anywhere: S3, Backblaze B2, Azure, Google Cloud Storage, Google Drive, OneDrive and Dropbox. These are reachable over the internet, so with your master key (or recovery phrase) and your storage login you can restore onto any machine, anywhere.

Restorable only from the same network: an SMB share on a NAS. The share answers on your LAN and nowhere else, so restoring from elsewhere means being on that network - in practice, a VPN back into it.

Restorable only with the drive: a local path or an external drive. The backup is on that disk. If the disk is in the building that burned down, so is the backup.

Depends on the server: SFTP and WebDAV can be either. A NAS at home behind your router is LAN-only in practice; a hosted server is reachable from anywhere. Whoever set it up knows which.

None of this makes a NAS or an external drive a bad choice - they are fast, cheap and private, and a local copy is the one that restores quickest. It does mean that if the destination is the only copy, its reachability is your recovery plan. The common answer is to run two sets: one to a local destination for speed, one to a cloud destination for the day the building is the problem.

The destination editor states this for you when you pick an SMB share or a local path, so you do not have to remember which is which.

Windows, macOS, and Linux - specifically:

• Windows: Windows 10 and Windows 11 (64-bit Intel/AMD), plus a native Windows 11 on ARM build.
• macOS: both Apple Silicon and Intel Macs. macOS 11 (Big Sur) is the minimum; newer releases are supported and tested.
• Linux (Intel/AMD 64-bit and ARM64/aarch64): a desktop package with the full app on both architectures, plus a headless package (background service + command-line/terminal tools only) on ARM64 only, for Raspberry Pi and ARM servers. There is no headless package for Intel/AMD 64-bit - on those machines install the regular package, which carries the same service and terminal tools alongside the desktop app. If you need one for a server, ask us: it is a decision rather than a limitation, and we will reconsider if people want it. The desktop package needs WebKitGTK 2.42 or newer - that is Fedora 39+, or Debian 12 / Ubuntu 22.04 brought up to date, since both shipped below it (2.40 and 2.36). Your package manager checks this and refuses the install with a clear message rather than letting the app fail at launch. The headless package has no such requirement: it installs on almost any Linux from the last decade, including older server distributions and container images. Validated on Ubuntu 22.04/24.04, Debian 12, Fedora 44, and Arch.
• 64-bit only on ARM - there is no build for 32-bit ARM (armhf), so a Raspberry Pi has to be running the 64-bit system. On Pi OS bookworm the desktop package needs updates first (it ships WebKitGTK 2.40); bullseye cannot reach 2.42 at all, so use the headless package there.

Every one of those is a real download: the current release publishes both Windows installers (Intel/AMD and ARM), both macOS installers, and the Linux .deb and .rpm for Intel/AMD and for ARM64.

Yes, on every platform. Windows binaries and the MSI are signed via Azure Trusted Signing (OV class). The macOS .pkg installer is signed with an Apple Developer ID and notarized by Apple, so it passes Gatekeeper cleanly. Linux .deb and .rpm packages are GPG-signed, and the public key is published at nyxbackup.com/keys/release.asc.

Download and run the signed MSI. It installs the background service (NyxBackupSvc), the desktop app, the command-line tool, and the text-based interface, and starts the service automatically. SmartScreen reputation builds with download volume since the certificate is OV-class.

Download the signed, notarized .pkg installer for your chip (Apple Silicon or Intel) and run it. Because macOS reads locked files via APFS snapshots, grant the service Full Disk Access when prompted; the app detects when Full Disk Access is missing and shows a banner.

Download the GPG-signed .deb or .rpm for your system, then install it with your package manager. Using the package manager (rather than a bare dpkg -i / rpm -i) lets it pull in any dependencies automatically, which matters for the desktop package.

Debian / Ubuntu (.deb):

# Desktop package (Intel/AMD 64-bit):
sudo apt install ./NyxBackup-<version>-amd64.deb

# Desktop package (ARM64 - Raspberry Pi, Ampere, Graviton, ARM laptops):
sudo apt install ./NyxBackup-<version>-arm64.deb

# Headless package (ARM64 servers, Raspberry Pi - service + terminal tools only):
sudo apt install ./NyxBackup-<version>-arm64-headless.deb

# On an Intel/AMD server with no desktop, install the amd64 package above.
# There is NO amd64 headless package - the regular one carries the same
# service and terminal tools, it just also installs the desktop app.

# Or the low-level way (then fix any missing deps):
sudo dpkg -i NyxBackup-<version>-amd64.deb && sudo apt-get -f install

Fedora / RHEL / openSUSE (.rpm):

# Desktop (Intel/AMD 64-bit):
sudo dnf install ./NyxBackup-<version>-x86_64.rpm

# Desktop (ARM64):
sudo dnf install ./NyxBackup-<version>-aarch64.rpm

# Headless (ARM64 servers - service + terminal tools only):
sudo dnf install ./NyxBackup-<version>-aarch64-headless.rpm

# On an Intel/AMD server with no desktop, install the x86_64 package above.
# There is NO x86_64 headless rpm.

# Or: sudo rpm -i NyxBackup-<version>-x86_64.rpm

Raspberry Pi: use an ARM64 package on a Pi 3, 4, or 5. The system has to be the 64-bit Raspberry Pi OS - there is no 32-bit ARM build.

Which package depends on your OS version. The desktop app needs WebKitGTK 2.42 or newer: bookworm ships 2.40, so apply updates first if you want the graphical app, and the older bullseye cannot reach 2.42 at all. The -headless package has no such requirement - it is built against a deliberately old system library floor and installs on anything from roughly 2018 onward - so on bullseye, or on a Pi with no screen, take that one and set it up with the terminal interface (nyx_bkp_tui) or the command line.

Everything else - scheduling, encryption, every storage destination - works the same either way.

Installing registers and starts the systemd service and creates the runtime, state, and log directories. If you want to verify authenticity first, import the release key from nyxbackup.com/keys/release.asc and check the package signature before installing.

Yes, optionally. The service checks a published update feed on a cadence you choose (Never, Daily, Weekly, Monthly), compares versions, and verifies the download's SHA-256 plus the operating system code signature before installing. Auto-install is off by default - it notifies you and installs only when you approve. macOS additionally uses the standard Sparkle update framework with a cryptographically signed feed.

On Windows, logs are in C:\ProgramData\NyxBackup\logs\. On Linux the service uses /etc/nyxbackup/ for config, /var/lib/nyxbackup/ for the database, and /var/log/nyxbackup/ for logs. On macOS it uses /Library/Application Support/NyxBackup/ and /var/log/nyxbackup/. User-mode installs use the equivalent per-user directories.

Only through a private local channel on your own machine - never over the network. The service confirms the request is coming from you (the logged-in user), so no one on your network or the internet can reach or control it. No network port is opened for control.

Yes. Which package depends on the architecture.

On ARM64 - a Raspberry Pi, an ARM NAS, an ARM server - use the -headless package. It is just the background service plus the command-line and terminal tools, with no desktop dependencies and a very low system-library floor, so it installs on server distributions and minimal container images.

On Intel/AMD 64-bit install the regular .deb or .rpm. There is no headless build for that architecture: the regular package contains the same service and terminal tools, and simply also installs the desktop app, which brings the WebKitGTK and GTK3 libraries with it. That is a real cost on a minimal image, so if a headless Intel/AMD build would be useful to you, tell us - it is a decision rather than a limitation, and one we will revisit if people ask.

Either way you drive it over SSH with the terminal or command-line tools.

Two different causes, both outside Nyx Backup itself - it draws through WebKitGTK, the same engine GNOME Web uses, and inherits its display settings.

Text too small or too large. GTK has two scaling controls and they do different jobs:

# Whole-interface scaling - INTEGER values only (1, 2, 3).
GDK_SCALE=2 nyx_bkp_gui

# Fractional text scaling - use this for anything in between.
GDK_DPI_SCALE=1.4 nyx_bkp_gui

# They combine: 2x interface with slightly smaller text.
GDK_SCALE=2 GDK_DPI_SCALE=0.9 nyx_bkp_gui

GDK_SCALE ignores fractional values, so GDK_SCALE=1.5 appears to do nothing at all. That is the usual reason scaling seems not to work.

Blank white or black window. Most often WebKitGTK's DMABUF renderer, which frequently fails under virtual-machine graphics. The app is running normally behind it:

WEBKIT_DISABLE_DMABUF_RENDERER=1 nyx_bkp_gui

If that fixes it, it is the graphics path and not the build.

Making it stick. Add the variables to the desktop entry so the launcher uses them too. Copy the shipped file rather than editing it, since a package upgrade replaces the original:

cp /usr/share/applications/nyxbackup.desktop ~/.local/share/applications/
# then edit the Exec= line in your copy, for example:
#   Exec=env GDK_DPI_SCALE=1.4 /usr/bin/nyx_bkp_gui

None of this affects backups. The background service has no display and is unaffected by any of these settings.

Start with the platform's normal removal, which takes out the app and its background service:

• Windows: Settings -> Apps -> Nyx Backup -> Uninstall (this stops and removes the NyxBackupSvc service and the program files).
• macOS: run the included uninstall command (the .pkg has no built-in uninstaller), which removes the app bundle and the background service.
• Linux: sudo apt purge nyxbackup (or sudo dnf remove nyxbackup).

That removes the program, but a complete wipe also means deleting the local data folder (config, the state.db chunk index/history, and logs) and the secrets held in your OS keystore (the encryption key, the license entry, and each destination's stored credentials). Two important warnings before you do: deleting the encryption key is irreversible - it is the only thing that can decrypt your remote backups, so export it first with nyx_bkp_cli export-key if you might ever want your data back; and run nyx_bkp_cli license deactivate first to free your license seat for another machine. Uninstalling never touches the backups themselves - they stay in your storage destination (and that provider keeps billing) until you delete them from the provider's console.

For the exact per-platform commands - including the keystore entries, their names, and the storage-provider cleanup - see the full guide at https://nyxbackup.com/uninstall.

The first-run wizard generates your master key (or lets you import an existing one from another machine), shows you the recovery passphrase to save, and requires you to confirm you have saved it before continuing. There is also a goal-based onboarding wizard that helps you pick sources, connect a destination, and set a schedule.

Choose the sources to protect, connect a destination (enter keys, or click Connect for an OAuth provider), pick a schedule, and set retention. For OAuth destinations a successful authorization counts as a verified connection, so you do not need a separate Test step.

A backup set can be set to run Manually (only when you start it) or on a timed schedule: Hourly, Daily, or Weekly. Whatever the schedule, you can also start a set on demand at any time with "Back up now" from the app, the tray, or the command line. Timed runs can be deferred while on battery, on a metered connection, or on specific Wi-Fi networks; a manual run you start yourself bypasses the metered guard.

Yes - this is one of the most important safety features in a backup tool. Each set can alert you when it has gone too long without a successful backup (a "dead man's switch" against silent failure). You can leave it on automatic, which bases the threshold on the set's own schedule, or set an explicit window yourself - for example, alert me if no backup has succeeded in 12, 24, or 48 hours - or turn it off. That way a disconnected drive, an expired cloud token, or a machine that was off does not quietly leave you unprotected.

Beyond sources, destination, and schedule, each set exposes: retention rules; your own exclusions (paths, patterns, extensions); pre- and post-backup commands (hooks); schedule guards that defer on battery, on a metered connection, or off specific Wi-Fi networks; a storage tier (including cold/archive tiers); handling of cloud-only "online-only" files; a backup priority; and the missed-backup alert above. Separately, an app-wide setting lets you cap upload/download speed, including only during set hours of the day (see the bandwidth question below). Sensible defaults are chosen for you, so you only touch any of this if you want to.

The desktop app's interface is available in 24 languages. You can pick one in Settings, or leave it on "System default" to follow your operating system's language. The available languages are: English, Spanish, French, German, Italian, Portuguese, Dutch, Swedish, Polish, Russian, Japanese, Simplified Chinese, Korean, Turkish, Czech, Ukrainian, Greek, Vietnamese, Hungarian, Romanian, Finnish, Norwegian (Bokmal), Danish, and Hindi. If you spot a translation that could be clearer or more natural, we would genuinely like to hear it - email support@nyxbackup.com and we will improve it in a later update.

A maintenance window is a period during which scheduled and manually triggered backups are suppressed (for example, during business hours). It does not cancel a backup already in progress, and you can set or clear it from the desktop app or the command line.

Retention keeps all snapshots within the last N days (default 30), one per week for the last W weeks (default 12), and one per month for the last M months (default 24). Auto-delete is off by default - the app logs what would be removed rather than deleting it - and you can turn on automatic cleanup that runs after each successful backup. Retention is editable per set with presets and inherit-or-custom modes.

There are two layers. First, each backup set has your own exclusions - paths, glob patterns, and file extensions you set in the app. Second, on top of that the app applies a built-in, operating-system-aware exclusion list so it automatically skips things that should never be backed up (system caches, temporary files, page/swap files, and Nyx Backup's own state and logs). That built-in list lives in a per-platform file - windows_exclusions.toml, macos_exclusions.toml, or linux_exclusions.toml - in the app's exclusions folder, and it is even tailored to your specific OS version (for example, Windows 11 vs a Windows Server edition). On Windows the app also merges the system's own "FilesNotToBackup" registry list.

Advanced users can customize the built-in layer without losing changes on update. Do not edit the shipped *_exclusions.toml directly - it is overwritten on each upgrade. Instead drop your own .toml file into the exclusions.d folder next to it: those files are additive and survive upgrades. A drop-in can add patterns, and an optional [unexclude] section can remove a specific built-in pattern if a default is excluding something you actually want backed up. For most people the per-set exclusions in the app are all they will ever need; the files are there for power users and managed deployments.

Yes. In Settings you can cap upload (and download/restore) speed, and turn on a daily window so the cap applies only during set hours - for example, throttled during work hours and full speed overnight. Outside the window backups run unthrottled, and changes take effect on the next run.

Set the log level in Settings; the service applies it live without a restart and persists it across restarts. Logs rotate automatically (at 6 MiB, keeping two compressed archives).

Yes. The desktop app ships with several built-in themes: light, dark, a "follow my system setting" option, the signature default look, and popular schemes such as Dracula, Nord, Solarized, and Catppuccin. Your choice is remembered between sessions.

Yes. In the backup set there is a checkbox, "Treat this source as removable / external / network." Tick it when the files you are backing up live on storage that is not always connected: a USB flash drive, an external HDD/SSD, an SD card, or a network share (SMB/NFS/WebDAV) that isn't always mounted. It is auto-ticked when the app detects a source on removable media, and it only appears when it is relevant (a removable/network source, or a set already marked removable) - it won't clutter a plain internal-disk set.

What it does: if that storage is not present when a backup is due, the run is simply skipped instead of failing - so an unplugged drive does not turn into a stream of errors or, worse, make the app think all your files were deleted. Reconnect it and the next scheduled run (or a manual "Back up now") continues normally. If you click "Back up now" while the drive is disconnected, the app tells you the run was skipped (rather than doing nothing visibly).

Mixed sets are handled per-source: if one set contains both an always-present folder (say on your internal disk) and a folder on a removable drive, and the removable drive is unplugged at backup time, the present folder is still backed up normally, and the unplugged folder is carried forward - the new snapshot keeps it exactly as it was at its last backup. It is treated as "not connected right now," never as "deleted," so nothing is lost and the whole set does not have to wait for the drive.

A bonus for local external drives: the set is also matched to the drive itself (by its volume identity), so it keeps working even if the drive comes back as a different drive letter or mount point - and the app updates the set to point at the drive's current location. That drive-matching applies to local disks only; a network share is matched by its path, so keep its mount path stable.

Note this checkbox is about your backup SOURCE. It is unrelated to a backup DESTINATION (S3, a NAS, an SMB/SFTP/WebDAV target) being temporarily offline - that case is handled automatically: the app retries briefly and then fails the run cleanly, without harming existing backups, and resumes on the next run once the destination is reachable again.

We do not recommend a USB-attached drive as your primary backup destination. Nyx Backup supports it, works hard to tolerate its failure modes, and it makes an excellent SECOND copy - but as the place your backups actually live it has three weaknesses that no amount of care on your side removes:

• No redundancy. It is one device holding one copy. Cloud object storage keeps several replicas across separate hardware and repairs itself silently; a single drive does not. When it fails, your backup fails with it - and a backup destination is the one thing you cannot afford to lose at the same moment you need it.
• It is often not there. A removable drive gets unplugged, borrowed, taken to another desk. Nyx Backup skips a scheduled run when the destination is absent rather than failing noisily - the right behaviour, but it means backups quietly do not happen, and the newest snapshot can be far older than you assume. Check the set's last-success date rather than trusting the schedule.
• It is in the same place as the data it protects. A fire, a flood, a burglary, or a spilled drink takes the original and the backup together. Offsite is the entire point of the second copy.

A thumb drive or flash stick is worse again and should not be a destination at all: cheapest available controllers, no thermal headroom, wear-out with writes, and a habit of failing suddenly and completely rather than degrading in a way you would notice in time. They are built for occasional file transfer, not hours of sustained writing. Backing one UP as a source is fine.

The shape we do recommend is a cloud destination as the backup that must be correct, and - if you want it - a local external drive alongside it as a fast first copy that restores without a network. Two destinations, two failure modes, neither depending on the other.

If you are going to use one anyway, these cost nothing and materially change the outcome:

1. Format it NTFS on Windows (APFS or HFS+ on macOS, ext4/XFS on Linux). Use a journalling filesystem. exFAT is the factory format on most portable SSDs and is tempting because Windows and macOS both read it - but it has no journal, so an interrupted write can leave the volume inconsistent with no recovery path. That matters more on a destination than anywhere else, because it is the copy you turn to when the source is gone. 2. Plug it into a native USB-C port on the machine, or a hub with its own power supply. A USB-C drive on a passive USB-C-to-USB-A adapter is limited to 4.5 W, and a portable SSD under sustained writes commonly wants 5-8 W. 3. Stop Windows powering the port down: Device Manager -> the hub or root hub -> Properties -> Power Management -> untick "Allow the computer to turn off this device to save power", and set Power Options -> USB settings -> USB selective suspend to Disabled. 4. Check that it is actually running. Because a missing drive means a skipped run rather than an error, the failure you should look for is silence. Watch the set's last-successful-backup date, and consider the overdue alert so a set that has not run in N days tells you so.

What goes wrong, and why it is not usually a dying drive

An earlier answer covers a drive that is simply not plugged in. This is about a drive that IS connected and still misbehaves: it stays mounted, the backup keeps running, but individual reads fail for a moment. On Windows that shows up as errors like "the volume for a file has been externally altered so that the opened file is no longer valid," "a device which does not exist was specified," or "the device is not ready." The usual causes are a bus-powered drive browning out when a large file spins up sustained reads, a marginal cable or hub, aggressive USB selective-suspend, or controller firmware in an inexpensive enclosure that re-enumerates the volume under load. Long, read-heavy jobs are exactly the workload that provokes it, and a full backup of a large drive is about as read-heavy as it gets.

What Nyx Backup does when that happens: it reads the file again. A fault like this almost always clears immediately, so each file gets up to three attempts with a short pause between them before it is given up on. Faults that are not going to clear are not retried - a file locked by another program, or one that has been deleted, is reported straight away rather than holding up everything behind it.

If a file still cannot be read after those attempts, it is left out of the backup, the run continues at full speed, and the run is reported as PARTIAL rather than successful, with a count of the files that could not be read. The service log names the exact paths.

Nothing is quietly lost. A file that could not be read is never recorded as backed up, so the next ordinary backup reads it again. In a measured case on a 324 GB backup from a USB drive, two files were skipped this way, and the very next incremental run read exactly those two files out of 63,899 and nothing else. You do not need to reset the set or start over; just run the backup again, or wait for the next scheduled one.

What is actually happening, in Windows' own words. This is usually not a dying drive. Under sustained I/O a USB volume is often torn down and re-created - the Windows System log records it as the volume's device number changing, for example \Device\HarddiskVolume779 becoming ...780, wrapped in "failed to flush data to the transaction log" and "{Delayed Write Failed}". The whole episode takes a couple of seconds. Every file the backup or restore had open at that moment becomes invalid instantly, which is why the errors say "the device is not ready", "a device which does not exist was specified", or "the system cannot find the path specified" rather than reporting a timeout.

Nyx Backup rides this out: a file is retried for several seconds before it is given up on, and each retry re-opens the file, because a handle to a volume that no longer exists can never be made to work. It is worth knowing the cause though, because the natural conclusion - that the drive is failing - is usually wrong, and so is the conclusion that your backup is damaged.

Practical advice, cheapest and most effective first:

• Stop Windows powering the port down. Device Manager -> the USB hub or root hub the drive is on -> Properties -> Power Management -> untick "Allow the computer to turn off this device to save power". Also set Power Options -> USB settings -> USB selective suspend to Disabled. This costs nothing and is the first thing to try: a port suspended mid-transfer, with a device that does not resume cleanly, produces exactly the re-enumeration described above.
• Give the drive enough power. A USB-C drive on a passive USB-C-to-USB-A adapter is limited to what the USB-A port supplies - 900 mA at 5 V, or 4.5 W - because a passive adapter cannot negotiate USB-C current advertisement. A portable SSD under sustained writes commonly wants 5-8 W. Use a native USB-C port, or a hub with its own power input, so the drive is not starved.
• Prefer an external SSD or HDD in a decent enclosure over a thumb drive. Flash "sticks" use the cheapest available controllers and have no thermal headroom; they are built for occasional file transfer, not for hours of sustained reading.
• Use a powered enclosure or a powered hub for anything mechanical. Many of these failures are power delivery, not the disk.
• Format the drive NTFS rather than exFAT if it will be a Windows backup SOURCE. exFAT is convenient because macOS and Windows both read it, but Windows cannot take a Volume Shadow Copy of an exFAT volume, because VSS is an NTFS/ReFS feature. Without a shadow copy, files that are open while the backup runs cannot be captured consistently, and the backup is reading the live filesystem rather than a frozen point-in-time image of it.

None of these eliminate the re-enumeration described above - it is a property of how the drive is attached, not of the particular drive - so they reduce how often you see it rather than stopping it. That is why the tolerance is built in rather than left to you to work around.

If a particular drive produces skipped files on run after run, that is the drive telling you something. Copy its contents somewhere else and retire it.

Yes. During a backup the scanner detects cloud-only placeholder (Files-On-Demand) files and does not silently download them just to back them up; skipped cloud-only files are surfaced to you so nothing is quietly missed.

Install Nyx Backup on the second machine and, during first-run setup, import the master key from the first machine - either the raw 64-character hex, or the file produced by nyx_bkp_cli export-key. Backups taken on the first machine then become readable on the second. Point each machine's sets at the same destination if you want them to share it; namespacing keeps them from colliding.

Do this during first-run, not afterwards: once a machine has generated its own key it will refuse to replace it, and importing then requires clearing the stored key first. If the second machine has already been set up with a key of its own, anything it has backed up stays tied to that key. See "Should all my computers use the same encryption key?" above for whether sharing one is the right call in your situation.

The app is a front-end for the background service; "offline" means it cannot reach it. Confirm the service is running (Windows: sc queryex NyxBackupSvc or net start NyxBackupSvc; Linux: systemctl status the service; macOS: check the launchd daemon). A single unreachable storage destination has, in some cases, been able to stall the service long enough to look offline; if a backup to an offline SMB/WebDAV share is running, stopping/disabling that set and restarting the service clears it.

That was a known issue with unreachable endpoints on disabled or removable sets. Non-data-movement operations now use a bounded retry policy so a dead endpoint fails in about a minute instead of retrying forever, and a service restart stops any stale loop immediately. If you see it, restart the service and disable the set until the share is back.

That is Dropbox's desktop sync, not Nyx Backup. Use Dropbox Selective Sync on that computer to exclude the Apps/Nyx Backup folder. Do not use Dropbox "Ignore," which deletes the cloud copy (your backup). See the Dropbox sync-back note under Storage Providers.

Re-connect the endpoint (Settings, select the endpoint, re-run the OAuth flow) so a fresh token is minted. Refresh tokens are bound to the OAuth app that issued them; if you switched to your own OAuth credentials, you must restart the service and re-authorize, because old tokens do not carry over.

That happens when something is still holding a handle to the service - commonly an open Services console (services.msc) or Task Manager. Close those windows and retry; a reboot is not required.

The Windows installer is signed with an OV-class certificate, whose reputation builds with download volume, so early downloads may still see a SmartScreen prompt. Verify the publisher shows as Nyx Software, LLC, and proceed. This does not indicate tampering.

Common reasons: it was locked and could not be read even via the snapshot mechanism, it matched an exclusion rule, or it was a cloud-only placeholder file the app intentionally did not download. Locked-file and skipped-file events are logged per file, and skipped cloud-only files are reported so you can see exactly what was left out.

The macOS service needs Full Disk Access to read protected locations and to take APFS snapshots. Grant it in System Settings (Privacy and Security, Full Disk Access); the app shows a banner when it detects the permission is missing.

No. Restores checkpoint each completed file and resume automatically when the service comes back, skipping files already written. If a restore is "paused - service offline," starting the service resumes it from its checkpoint.

A non-clean scheduled integrity result raises a high-priority notification and a persistent banner. Re-run the check to confirm; if packs are genuinely unreadable, the affected snapshots may be unrestorable and you should run a fresh full backup. Contact support@nyxbackup.com with the log if you need help interpreting it.

It should not, beyond rounding. Nyx Backup reports storage in decimal GB (1 GB = 1,000,000,000 bytes), the same unit Google Cloud Storage, Amazon S3, Backblaze B2 and macOS Finder use, so the size shown in the app and the size on your bill should describe the same thing.

Small differences are still normal. Your provider counts every object in the bucket, including packs left behind by snapshots that retention has since removed, and it bills on a daily average rather than a point-in-time figure. If the gap is bigger than that, open Retention & GC for the set and use Run GC Now, which deletes packs no longer referenced by any snapshot.

One place will still disagree: Windows Explorer divides by 1024 and calls the result "GB", which makes the same data look about 7 percent smaller there. Explorer is the outlier - your provider, your bill, and macOS Finder all use decimal.

Email support@nyxbackup.com. Logs are on Windows in C:\ProgramData\NyxBackup\logs\, on Linux in /var/log/nyxbackup/, and on macOS in /var/log/nyxbackup/ (or the per-user Logs directory). The background service and each front-end (desktop app, command-line tool, and text-based interface) write their own log file.

Yes, fully and publicly, at nyxbackup.com/format. It specifies the object layout, the encryption envelope, the pack file structure, the CBOR manifest schema, the key-derivation hierarchy, and the complete restore algorithm - enough for an independent developer to write their own reader.

Format version 2, and it is stable and backwards compatible. A future reader is committed to reading version-2 archives, and any format version bump would come with a major version bump of the app itself.

CBOR (RFC 8949), wrapped in an authenticated-encryption envelope (AES-256-GCM). Config files are TOML, and the command-line tool's machine-readable output is JSON. Backup data is never stored as JSON.

In principle, yes - and that is by design, so you are never locked in. The complete on-disk format is publicly documented, so with your master key and read access to your storage, your archives can be reconstructed by following the published specification. Your data is not trapped inside one vendor's software.

A pack is a container that bundles many small backup pieces together (more efficient than storing millions of tiny objects). Each piece inside is individually encrypted and compressed, and the pack carries an index so the app can find any piece quickly. Every pack is stored under a path namespaced to your machine and backup set. The full structure is documented in the format specification at nyxbackup.com/format.

Yes. Everything needed to restore lives in the destination: the plaintext bootstrap record lists your sets, the encrypted snapshot index lists snapshots, and each manifest describes a snapshot's files and chunks. The local database is a cache and index for speed, not the source of truth for restore. The command-line tool can rebuild the local database from the destination.

Special files (FIFOs, sockets, devices) are intentionally skipped - they have no meaningful contents to back up. Hard links are not preserved as links: a file with multiple hard links is stored once (deduplicated) but restored as independent copies at each path. Symlinks are preserved.

Nyx Backup is a product of Nyx Software, LLC. It is not a first attempt: it was built by a veteran of the backup industry with decades of software development experience, including years spent building online backup specifically - the same engineer built AltDrive Online Backup, which ran from 2005 to 2018. In other words, the hard, unglamorous lessons about what makes a backup tool trustworthy (correct incrementals, reliable restores, safe retention, sane handling of locked files and cloud storage quirks) are already baked in. Support is support@nyxbackup.com; privacy questions go to privacy@nyxbackup.com; security disclosures go to security@nyxbackup.com.

The product is new, but this is not our first rodeo - the people and the engineering behind it are not new to backup. Three things back that up:

• Experience. Nyx Backup comes from a developer who spent over a decade running an online-backup service (AltDrive Online Backup, 2005-2018, also resold white-labelled by other companies to their small-business customers) and decades writing software generally. The design reflects hard-won lessons about incrementals, restores, retention, and edge cases, not a weekend project.
• Engineering rigor. The core backup and restore logic is covered by an extensive automated test suite (hundreds of tests across the codebase) that runs on every change, so behavior stays correct as the product evolves.
• No lock-in, by design. You do not have to take any of that on faith. The entire on-disk format is fully published, and the encryption is zero-knowledge, so we could not read or hold your data hostage even if we wanted to - and because the format is documented, your data is readable from the spec, never trapped in a proprietary black box.

That combination - real domain experience, tested code, and a design that does not depend on trusting the vendor - is the case for trusting a newer product.

Your data remains recoverable. It sits in storage you control, encrypted with a key you hold, in a fully documented format. Because the format is public, your archives can always be read from the specification - nothing about recovering your files depends on Nyx Software continuing to exist or run any server.

No - Nyx Backup is proprietary software. What is open is the thing that matters for lock-in: the complete on-disk data format is publicly published, so your backups are never held in a secret format only our code can read. You get the durability benefit of an open, documented format without the product itself being open source.

It is built entirely on standard, battle-tested algorithms rather than anything homegrown: AES-256 for encryption, SHA-256 and HMAC for integrity, HKDF for key separation, Argon2id or PBKDF2 for turning a passphrase into a key, and Ed25519 for signatures. These are the same building blocks trusted across the security industry, and on each platform they run through the operating system's vendor-validated cryptographic module rather than an unproven in-house implementation. The cryptographic implementation and how the pieces fit together have also been reviewed in depth with the help of an advanced AI analysis agent, and the on-disk format is fully published so the design is not a black box.

The app is architected to minimize what Nyx Software could hold: no data in our path, keys never sent to us, and telemetry that is opt-out and carries no file data, paths, credentials, or hostnames. Formal Privacy and Terms documents are published at nyxbackup.com/legal. Privacy requests go to privacy@nyxbackup.com.

Email security@nyxbackup.com, and the website publishes a security.txt with the disclosure details. We welcome responsible disclosure.

There is nothing to sell - your backup data never reaches us. The only data Nyx Software receives is optional, pseudonymous aggregate telemetry you can disable, and it contains no personal content.

They are published on the website and mirror the in-app text:

• License agreement (EULA): nyxbackup.com/legal/eula
• Terms of Service: nyxbackup.com/legal/terms
• Privacy Statement: nyxbackup.com/legal/privacy
• Refund Policy: nyxbackup.com/legal/refund

Yes - the changelog is published on the website at nyxbackup.com/changelog, and when the app finds an update its Settings screen links straight to the release notes for that version. Some capabilities described in internal requirements (for example, Reed-Solomon parity packs and an automated disaster-drill mode) are deferred or not yet built - see the verification notes below and do not present them as shipping features.