Mails with wrong content
-
Yes, I see it also in WebApp.
So, when I will do it with a kopano-backup restore, the steps will be:
1.) make sure /var/lib/kopano exists and is empty at the new system
2.) user stores on the new system must be empty
2.) run kopano-backup restore on the new system
3.) run rsync -a from old kopano system to the new oneIs this ok so ? How can I delete existing user stores on the new system, with kopano-cli --remove store ?
Because I already use the new system, what will be the right way to get the actual state again: Cleaning all as mention above, then run a kopano-backup restore with the last backup from the old system, then a kopano-backup restore from the new system (skipping the existent entries). Or is it just enough to clean all and run a kopano-backup restore with the complete (scrambled ?) data from the new kopano system ?In the moment I feel a little confused … What is the right time to do the rsync of the attachment folder: Before or after the kopano-backup --restore ??
-
@mpetersen said in Mails with wrong content:
3.) run rsync -a from old kopano system to the new one
no, exactly not this one step. Kopano-backup already includes everything from your user. you just have to be aware that it will not be an identical clone, but merely a copy (since data needs to be serialised in and out, also creation timestamps will be of the time of the restore).
@mpetersen said in Mails with wrong content:
Because I already use the new system
I would discard all backups done after your restore and start with the machine from scratch.
-
No rsync ? On the old kopano system the attachments were already stored in the file system and if I understand aright from documentation the kopano-backup command only save the mails, but not the attachments. So I misunderstand this part and /var/lib/kopano must bot backup separately ?
-
@mpetersen said in Mails with wrong content:
if I understand aright from documentation the kopano-backup command only save the mails, but not the attachments
No, that is indeed not the case. kopano-backup stores complete messages including their attachments.
Maybe you mixed up https://documentation.kopano.io/kopanocore_administrator_manual/backup_restore.html#brick-level-backups with the previous chapter?
-
My understanding came from https://documentation.kopano.io/kopanocore_administrator_manual/backup_restore.html#attachments-backup:
"When using the attachments storage outside the database, make sure that these attachments are also backed-up.
Some backup methods that can be used to backup the attachments:- Rsync"
When you mentioned “start from scratch” it means, that I will lost all my mails after the time of the restore from the last backup of the old system, that would be very silly …
-
@mpetersen said in Mails with wrong content:
When using the attachments storage outside the database, make sure that these attachments are also backed-up.
that quote is in relation to chapter “10.2. Full database dump”, kopano-backup is explained in chapter “10.3. Brick-level backup”.
@mpetersen said in Mails with wrong content:
When you mentioned “start from scratch” it means, that I will lost all my mails after the time of the restore from the last backup of the old system, that would be very silly …
You mentioned that even newly created mails show inconsistencies. While you cannot apply a date filter when generating a backup with kopano-backup you could set one when restoring. But I am not sure if I would trust that data myself (since it was inconsistent before the backup).
-
Hi @fbartels
I started from scratch and run the restore from the last backup of the old kopano system:
/usr/sbin/kopano-backup --restore /var/backups/nfs/kvm/user -u user --recursive -l DEBUGI got a lot of “[error ] Unable to open attachment “/var/lib/kopano/attachments/x/x/xxx{.gz}” for writing: Datei oder Verzeichnis nicht gefunden”
At the end there is no entry in /var/lib/kopano/attachments, simply nothing ! Is this ok ?
-
@mpetersen said in Mails with wrong content:
At the end there is no entry in /var/lib/kopano/attachments, simply nothing ! Is this ok ?
The only way in which this was ok was when you actually have another path configured in your server.cfg…
@mpetersen said in Mails with wrong content:
Unable to open […] for writing
It sounds like the volume you are trying to write to does not permit you to write to it.
-
I gave up and switch back to the status of this morning.
The rights of the attachment folder are set correctly:
root@kopano:/var/lib/kopano/attachments# ls -al
total 48
drwxr-x— 12 kopano kopano 4096 Jan 2 21:39 .
drwxr-xr-x 11 kopano kopano 4096 Dec 28 19:51 …
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 0
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 1
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 2
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 3
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 4
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 5
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 6
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 7
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 8
drwxr-xr-x 22 kopano kopano 4096 Nov 9 2012 9
root@kopano:/var/lib/kopano/attachments#
And there are already files in there with actual date eg.
274502 4 -rw-r–r-- 1 kopano kopano 2899 Dec 31 15:03 ./6/6/14066.gzI think I have to decide if I accept data loss from the past or some data corruption in the present. What a silly choice …
And I will switch my backup procedure from kopano-backup to lvm snapshot, which seems more reliable in my opinion.
Thanks for helping so far.
-
@mpetersen said in Mails with wrong content:
The rights of the attachment folder are set correctly:
maybe your unterlying filesystem prevents writes?
@mpetersen said in Mails with wrong content:
What a silly choice …
your use of “silly” really irks me. I personally find it very silly to not test a migration and your backup strategy beforehand.
@mpetersen said in Mails with wrong content:
And I will switch my backup procedure from kopano-backup to lvm snapshot, which seems more reliable in my opinion.
You do you, but the downside of lvm snapshots is that you have to make sure that all temporary data has been written to disk before the snapshot’, else you risk creating inconsistent database records.
For a full disaster recovery I would always go for mysqldumps plus file system backups and kopano-backup to fill up any differences and be able to do partial restores for users.
