NethServer Version: 7.7.1908 Module: backup and mail
I just tested a disaster recovery on another VM with a clean install, same version. This seemed to work and all mailfolders and users are recreated. But, when I try to login with a mailuser to IMAP the logs show:
Feb 20 22:36:31 cloud dovecot: imap(user@mydomain.com): Namespace '': stat(/var/lib/nethserver/vmail/user@mydomain.com/Maildir) failed: Permission denied (euid=984(vmail) egid=981(vmail) missing +x perm: /var/lib/nethserver/vmail, dir owned by 985:982 mode=0700) in=0 out=382
Now, it seems the user is recreated with a different UID? Or the user āvmailā is set with a different UID? Is this something I can prevent somehow?
I did a clean install of 7.7.1908 on another VM.
1a) I updated both servers before creating the backup and restoring it on the new server.
1b) I did NOT change the hostname of the new and fresh Nethserver install.
I downloaded the config from the 'production" server and restored it on the fresh Nethserver.
I connected the fresh server to the same backup location where a recent restic backup from the production server is located.
I restored that backup and reconfigured the interfaces afterwards.
I restored the above all from the GUI.
Now, all users and packages where restored as expected. Only when I try to connect to the IMAP server , I get the above logs about permission problems.
Between 1 and 2 did you fully updated your server before restore configuration?
Also: hostname for āanother VMā is the same of the old/dead one? (according to disaster recovery scenario)
Between 1 and 2 did you fully updated your server before restore configuration?
Also: hostname for āanother VMā is the same of the old/dead one? (according to disaster recovery scenario)
I did a full update on both machines before creating the update and after that, restoring it.
I did not change the hostname beforehand. The hostname of the new VM did change after restoring the config on it.
Should I retry with a new install and change the hostname beforehand you think?
I donāt think changing the hostname beforehand would help, as the name is changed during the restore to match what it wasā¦
I see this as a (small) bug: A full restore to a newly installed NethServer should just work.
The UIDs should be the same as on the old server. Otherwise a lot of problems can and will happen, like Windows Access to AD/Filesā¦
The predesessor of NethServer, SME-Server had a very well working backup. The main issue there was, the backup ONLY restored standard stuff. Any Add-Ons or Plug-Ins had to be manually installed BEFORE the restore, then it would work!
However, if you had stuff on the server no longer available (expired/replaced software, repos or other stuff), you had a big pronblem. NethServer solves this nicely by installing all software anew from the Software Repo. Other, manually installed stuff would still have to be handled separately.
AFAIK the restore of the whole server (not config) itās read only if the hostname of the backup matches the hostname of the restore target.
As docs stated⦠https://docs.nethserver.org/en/v7/disaster_recovery.html
1 install ānewā machine
2 restore config uploading the file of configuration
3 map interfaces logical with physical
4 start restore config
4 opt - login back if IP changed
5 go to data backup
6 start restore data.
Youāre right there, a full restore NEEDS the same hostname as the āoldā server. (Not the same IPā¦)
Iād also go for a full restore in this case.
That is also valid for a lot of other systems, even on my Macbook. (I can migrate the TimeMachine backup to a new running maschine, we in IT call that a restore, but technically itās NOT a restore, itās a migration, as the hardware is new! So the tool isnāt called TimeMachine anymore, itās called Migration utility or something like that)ā¦
Thanks all for your replies.
Iāve tested again from scratch.
Unattended install of Nethserver 7.7.1908 on a VM
Upgraded all software
Changed the hostname to the same as original server
Uploaded the config and restored it
Restored the data-backup from original server
Now, Iāve noticed that after the config-restore, I could access the IMAP folder of user1 which was correctly imported from the config. Of course the IMAP folder was still empty because I still had to do the data-restore.
After the data-restore, the data was indeed restored, but I get the same permission error on the IMAP folder (see above). So, this bug is introduced with the data-restore. Iām not sure how to proceed. Of course I need a working backup functionality before I take the original server in āproductionā.
Hope you can help.
What backup-data engine are you using? (restic, duplicity or rsync) Where? (CIFS, SFTP, etc).
I suspect that we may have permission problems using rsync over sftp with a non-root user over some destinations.
Sidenote: Iām getting the logs mailed after a successful backup of the original server and I noticed:
ā¦
Pre backup scripts status: SUCCESS
/sbin/mount.davfs: Warning: canāt write entry into mtab, but will mount the file system anyway at /etc/e-smith/events/actions/mount-webdav line 76.
ā¦
(But, on second thought, this might be due to concurrent backups running at same time and same webdav share since I restored the second server. Will shutdown backups on the new server and see what happens with the original backup routine.)
UPDATE:
After a lot of testing, restoring, etc, I now tried using the old GUI to:
Create a config backup from original server
Create a data-backup to a WEBDAV share
Restore the config (in old GUI) in the testserver
Restore the data-backup from the CLI with ārestore-data -b backup-dataā
This actually was successfull! Everything was restored with the right permissions.
So, there is something in the Cockpit GUI that runs the restore scripts differently that causes this. Iām very curious if anyone can reproduce this behaviour.
Q: Can I restore a Restic backup from the CLI? Iād like to test if that works better too.
Iām still trying to reproduce the problem, without success.
Maybe we are looking in the wrong spot, restore-data is ok, but the system you are restoring on has something that changes the vmail user id.
All backups can be restored from the shell, using their name. Example: