Backup & Restore Issues
Actual Backup & Restore Issues Homepage
Please see Ajcody-Backup-Restore-Issues
Performance Issues And Time To Complete
Please see Ajcody-Notes-BackupPlans
Backup or Restore In Progress
Please see url below for Backup In Progress - topic name "Aborting Full Backup In Progress":
Please see url below for Restore In Progress - topic name "Stopping a Restore Process" :
Restore To Time Problems
There's seems to be some syntax issues when using this variable. Please review the following to confirm your syntax.
The gist, you MUST use the -lb full-200xxxxxx option when your trying to restore anything that ISN'T meant to include the latest information of the mailbox. The -lb argument should specify a full backup that took place prior to the time of the backup you wish to restore.
zmrestore -a USER@DOMAIN.com -restoreToIncrLabel incr-20080731.060007.644 -lb full-20080726.050017.306 -br -ca -pre restore_
zmrestore -a USER@DOMAIN.com -restoreToTime 20080801011800 -lb full-20080726.050017.306 -br -ca -pre restore_
Backup label (-lb) for fulls can be found by:
zmbackquery | grep full
Backup labels (-restoreToIncrLabel) for incrementals can be found by:
zmbackquery | grep incr
Variables that are asking for TIME rather than LABELS should follow this syntax (from zmrestore --help):
Specify date/time in one of these formats: 2008/08/06 09:55:50 2008/08/06 09:55:50 572 2008/08/06 09:55:50.572 2008/08/06-09:55:50-572 2008/08/06-09:55:50 20080806.095550.572 20080806.095550 20080806095550572 20080806095550 Specify year, month, date, hour, minute, second, and optionally millisecond. Month/date/hour/minute/second are 0-padded to 2 digits, millisecond to 3 digits. Hour must be specified in 24-hour format, and time is in local time zone.
Some other url's to review are:
- zmrestore using restoreToTime option restores data after the specified time
- zmrestore -restoreToTime should fail if no backup label is passed
- Admin console issues and other details I've posted are in this bug:
- Added for search terms, admin console can't restore to point in time
Quota Is Stopping A Redirected Restore
Reasoning for need, maybe the msg files coming from the restore are no longer "shared message blobs" and therefore increase the mailbox to a size it wasn't in the past. Changes to HSM maybe?
I think I'll need to create a RFE about adding an option to the zmrestore command to also include an option to set the COS value on a created account. Until then... Create a new COS and set it up to NOT have any quota. Once you kick off the backup and you see the account is created you can then apply the COS to that account. Call the cos something like no-quota. Here's the steps below.
To copy your cos (assuming your quota cause is the default one, change default to match your production cos your using).
To see all cos's
Copies cos called default to cos named no-quota
zmprov cpc default no-quota
To remove quota to the new cos no-quota
zmprov mc no-quota zimbraMailQuota 0
zmprov gc no-quota | grep -i quota
Now you would start your redirected restore and once you see the account is created, run the below in a separate shell. (example)
zmrestore -a USER@DOMAIN.com -restoreToTime 20080801011800 -lb full-20080726.050017.306 -br -ca -pre restore-
Once restore has kicked off - To apply the no-quota cos to the restored account:
zmprov sac restore-USER@DOMAIN.com no-quota
Restoring A Calendar (ics)
There seems to be a bug or odd expectation on how this command is currently working. If the appointment exists in the Calendar and the time is different with the same appointment in the ics file your importing - the time of the appointment will not change to the imported ics one. If you delete the event first, then the imported appointment will reflect the correct time.
Here's what I did to reproduce this situation. It seems this has been true for sometime, customer was on 4.5.11 and I was on 5.0.8
Created test account and made two appointments on friday - 9am and 4pm. Did a full backup. Restored test account to restore_user Ran : zmmailbox -z -m firstname.lastname@example.org gru /Calendar > /tmp/calendarA.ics zmmailbox -z -m email@example.com gru /Calendar > /tmp/calendarB.ics And then diff /tmp/calendarA.ics /tmp/calendarB.ics [no differences] Now some tests. As user, I deleted the two appointments and then: zmmailbox -z -m firstname.lastname@example.org pru /Calendar /tmp/calendarB.ics Refreshed Calendar as User in webclient. 9am and 4pm appointment shows up. I then moved in the webclient the 9am appointment to 11am Did another restore: zmmailbox -z -m email@example.com pru /Calendar /tmp/calendarB.ics Refreshed Calendar as User in webclient. 11am and 4pm appointment shows up. ** The restore did not move the 11am appointment back to the 9am slot as in /tmp/calendarB.ics ** Assumption, this process will not over-write an appointment if it's there - it does not look to the time. Let's do a diff of the state of the calendar zmmailbox -z -m firstname.lastname@example.org gru /Calendar > /tmp/calendarC.ics diff /tmp/calendarB.ics /tmp/calendarC.ics The DTSTAMP and SEQUENCE shows the difference in the time. If I delete the 11am appointment and then do the calendarB.ics restore the appointment shows up again at 9am.
I see this same behavior if I also use the web interface to export/import the calendar between the restored account and user one. Even when I import it into a NEW calendar, which it even changes the two appointments to reflect the new calendar rather than the default one.
One fix, if the situation allows, is to purge the current Calendar and then import the full ics file. This would be done like this:
zmmailbox -z -v -m email@example.com ef /Calendar * ef is for emptyFolder zmmailbox help folder *webclient shows all events gone but Calendars are still listed. zmmailbox -z -v -m firstname.lastname@example.org pru /Calendar /tmp/calendarB.ics *webclient show all events with times as expected.
Haven't tried yet, but someone said you should be able to adjust the SEQUENCE number in the appointment and the import process will use that data (data/time) of the newer sequence number appointment.