NS8 - Backup and restore (Windows file share)

Hi all,

On the page: Backup and restore — NS8 documentation
Windows file share, through SMB2/3 protocols => absolutely no description at all !!!

And I’m not talking about the extremely poor description/utilisation of PASSWORD in the creation of Windows file share: “Repository password”, “Strong encryption passwor”, “Enter a passowrd to encrypt the backup”, “Set the encryption password”, “Change the encyption password”, “Password” under User name.

The worse one (bug) is in Advanced => Repository password => Enter password if repository was configured previously.
It doesn’t work with the password mentioned above, you have to use the encryption key for it to work and not the password.

“Strong encryption password”, is it a passphrase or a “word” used as a base to generate the encryption key???

Nowhere there is any mention of the encryption key. That’s the main problem (or bug).

Since NS8 initially didn’t include a firewall application and also the ability to backup locally (I have absolutely no confidence in storing my data on the Internet, no matter where), I was very skeptical regarding the adoption of NS8 by small and medium-sized businesses. And I don’t want to hit the nail on the head by writing about the dropping of the Debian subscription…

With the first stable version of NS8 including an SMB backup, I regained a “little” confidence and I am giving it a second chance. Bring back Debian’s subscription and I’ll become a fiery NS8 defender.

The SMB backup seems to work fine, but the restoration causes some problems. I’ll continue checking it and I will come back.


1 Like

Hi Michel, thank you for the heads-up!

This is a screenshot with the current UI labels

I agree that labels under the “Advanced” section can be improved. Maybe “Repository encryption key” is more understandable. This is a proposal:

The :information_source: icon, when clicked can fold out and convey the following concepts:

  1. The repository encryption key is saved in the cluster configuration backup
  2. If the repository already exists, the entered encryption key must match

/cc @andre8244 @giacomo

In the UI design we should respect the following rules when we write the text of the individual elements: Improve Backup UI clarity · Issue #6793 · NethServer/dev · GitHub

1 Like

I think generally, while legit, it’s very confusing (especially for newbies) to use the term “Repository” for a Backup Target.
So far the term is much more associated with Software Repositories, eg for Updates or such, in the sense of GitHub or such.

Why not a more clearer term like Backup Target?

This isn’t a competition with the old UNIX adage “everything is a file” in the sense of “every storage is a Repository”…

The english and eg the german terms and meanings are also different. In english, the usage is miore lenient, in German, it’s specifically “a managed, digital storage for source code”…

If I put in just the term repository in Google, here in german speaking Switzerland, this is the first answer shown:

Usage of the term Repository makes a simple Backup sound like a task for programmers, or makes a Backup sound like something to do with a religious sect, including special lingo…

My 2 cents

The use of the word “Repository” probably is inherited from the underlying backup engine (restic) which can have multiple repositories and the corresponding repository encryption keys.
For the main title “Add repository”, if it is not clear enough for users, it could be changed by something like Andy suggests (i.e. “Add Backup Target/Destination”).
For the field “Repository name” it makes sense both ways (as is or a more user friendly form like “Backup name” or alike).
For the encryption key, what Davide suggests makes sense.
Don’t know the current status of encryption key management, but it could make sense to warn the user to safeguard the encryption key (even if they are stored in the cluster configuration backup).


Other backup "Apps also have / use several Backup-Targets, without the user having to learn “programmer-specific” lingo…

It reminds me too much of the (stupid) statement by Linus Torvalds:

“Real men don’t do backups. They upload their stuff to the Internet and let the rest of the world mirror it!”…

Internet, of course, implying GitHub or whatever Repo was used in earlier days…

My 2 cents

Yes, I agree that both “target” and “destination” are better than “repository”.

I personally prefer “destination” over “target”. A “backup” resembles a parcel sent to a destination more than a bullet or an arrow directed to a target :slight_smile:

1 Like

Hi @davidep,

Thank you for your fast reply.

  1. I would prefer “Destination”, target might means the backup itself.
  2. Since the key is already stored somewhere, will it be better to get it and insert it directly in this field?
    Usually, the backups are all at the same place, else why not adding a check box to accept it or choose another one.
  1. I would prefer “The destination encryption key is saved in the cluster backup configuration.”
    [… backup configuration page]
    Should also points to where to copy it from.

  2. “An empty value generates a random key”
    Will it replace the original one or add it alongside with the original?
    Then, how to know which one to use and to which backup it belongs?

  3. There should be a very important note about “Replace” which will avoid having problems with a second same Instance with a different number.

  4. Etc… Backups are the nerves of the OS and the most important part.

Now, I have to check why there’s an error when I try to restore LDAP. If it’s possible to back it, it should be possible to restore it?


1 Like