Restore-data failed - does not overwrite files

NS latest release, up-to-date.

Restoring a backup from USB to new machine fails while restore-data does not overwrite files. In the gui while issuing the restore is the warning, that EVERYTHING will be overwritten during the restore.


It’s a full duplicity, how to restore this FORCING overwrite everything? Sorry, following the wiki and the path on the gui - this does not make sense to me.

Has somebody an idea?


Meanwhile I can report that the backup/restore wirh rsync was running through.


Struggling around the last days with migration from SME to NS, backup/restore, proxmox and NS itself, I’m too tired now to report. Right now it seems, that mostly the things are running. BUT - it was much easier to migrate to new hardware or backup/restore at the SME. AFFA did the job at any time. Easy, fast and reliable. Cavecats with NS to mention: sogo, hylafax, rspamd, hotsync, mailman, backup/restore with duplicity.

Conclusion for me is I don’t trust much the inbuild backup function(s). I’ll backup with proxmox.

Need a rest now.


I did some test, just be be safe, but I can’t reproduce the issue (if I understood it).
Could you post some screenshots of the UI pages you used and the output of ls before and after restore?


Unfortunately this was a migration in (during) production. I didn’t make screenshots of malfunctions. If it helps, here is what happend:

  1. Migration with the NS migration script from hardware SME 9.2 to hardware NS up-to-date. Before migration an AD was created.
    Before the final step I had to delete the information_schema.sql. Migration went through. For the users and ibays I had to reset all rights and group-belongings. I gave up with horde while I was not able get this running in stable. I moved to sogo. The migration of hylafax was not possible. If I’d known that a reinstall and configuration with the old server-manager (port 980) I’d rather have taken instantly this path. Migrating the firebird-superserver was easy - new install, move the database to the new server, done. Migration of mailarchiva (yes, very old version, but few 100 thsd emails) was not possible for me. Anyway, so far, so good.

  2. But what would a server be without backup and restore? The first attempts in my virtual environment were o.k. Of course I’m not able to test my running production server in a VM. The idea was to backup and restore the physical NS server (1TB partition) in a vm and to use this as a spare server. To keep the two servers in sync, I tried nethserver-hotsync. To make it short, a restore without errors was not possible. I gave up this one. Next try was the disaster-backup in NS. I started with duplicate. To make it short again, a restore was not possible. Funny thing - a warning appears before restore that all files will be overwritten. While following the messages with tail the restore complaints that files cannot be overwritten. And backup and restore was still meant to happen in the vm.

  3. While thinking about this experiences (and still liking NS) I thought over the proposal of Andy Wismer, who suggested to move the NS to proxmox and run it in a VM. At this point I thought this is the only way to have the security of a full functional backup/restore in a case of need. Problem was again no proper restore of a backup possible. I booted the physical NS (with the 1TB partition, at this time around > 300 GB data) with clonezilla. I setup a dedicated proxmox server with a VM for NS. I booted the NS VM also with clonezilla, and used clonezilla over LAN (disk-to-disk) to get the physical server in the VM. Of course, this was not bootable. I had to build the init new. BUT NOW I had my migrated SME in a functional NS VM.

  4. Still no goal, because I want to have a spare server. Therefore I setup a second dedicated proxmox with a second NS VM. I gave the disk 360 GB. Still the problem with the backup/restore from the other NS (remember 1TB partition). I tried disaster-backup/restore with duplicate again to move the data to the new VM, no luck. I tried it with rsync and got only one error to two hylafax-files. I checked the rest of the restore and found it o.k.

  5. Sogo didn’t start, I had to reinstall. Before the restore I made a dump of the sogo-database, after the reinstall contacts and calendar were gone. With restoring the dump everything was back again. Hylafax needed also a reinstall, same for mailman and for the firebird-superserver. Rspamd doesn’t like new/different hardware, I had to dump rspamd.rrd and move and restore it on the new VM. Unfortunately bayes is gone (I can live with that, we’re getting enough email to train this again.)

  6. Right now everything seems to be running. I have two dedicated proxmox with two NS as VM (and as a side effect the old SME with (only) the mailarchiva running. Backups are automated, I’m rsyncing the dumps of the production VM to the backup VM. I will not build a cluster with a separate network, it would be too much effort. In case of a hardware failure I’ll loose a few emails and a little work. Restoring a dump costs me some time, but I can live with that.

  7. Conclusion for me (and only for me): NS is it worth. I like it.
    Right now there are a lot of threads in the forum not even about painful migration from SME to NS, also about problems with backup/restore. Of course it’s always the customization of a server. Migration is surely not an every day task. It’s o.k. if things are not going this smooth. Rather I’d expect a rockstable and well documented backup and restore is a MUST for a production server. Don’t get me wrong, but I moved in the past 20 years really a lot SME servers with AFFA around. Backup/restore to the same hardware/server but also moving to new releases and hardware. It worked.