Ajcody-Backup-Restore-Issues: Difference between revisions

Line 279: Line 279:
====How Do I Figure Out Which Sequence or Time Variable To Use For Restore Or Replay====
====How Do I Figure Out Which Sequence or Time Variable To Use For Restore Or Replay====


Investigating at the time being.
To locate the correct restore-to time, you have to start with an approximate time the message was added/deleted.  Look at the redolog files.  The filename contains the GMT time when the file was rolled over, which is roughly the tstamp of the last operation in the file.  If your time data is accurate you can find the specific file.  Or you have a range of files to examine.
 
Use the redolog verify tool to dump the contents into text form, the -m / --message option to show message body data:
 
<pre>zmjava com.zimbra.cs.redolog.util.RedoLogVerify -m <filename or directory> ... > out.file</pre>
 
If the message was deleted and you don't know the id, you must go by some other clue such as the subject. Search the file to locate your message.  You can cut/paste the message and lmtp-inject it to recover the message.  No need to go through with a restore if this is all you needed.
 
In 5.0.10 we'll have a CLI wrapper (zmredodump) with a slightly different command line syntax, but the above long syntax works in earlier versions.


====Gap In Redo Log====
====Gap In Redo Log====

Revision as of 16:01, 30 September 2008

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

Understanding Option Flags For zmbackup & zmrestore

First, they don't make sense if your just reading from the help output - I will not argue this point at all.

The biggest problem with the options I point out below is that you can often include them in the command and they do nothing or you include them for a particular situation and they don't apply. Why is this a problem? Because they are silent and give no output telling you that it's not necessary, it's redundant, or it will actually cause your intended results to fail simply because you included the option.

zmrestore Options

Problems mostly revolve around these options.

To Times In The Past (If -lb Isn't Used, Implies Your Using Times/Incr/RedoSeq AFTER Last Full)
  • -restoreToIncrLabel
    • <arg> Replay redo logs up to and including this incremental backup
      • Requires: --label or -lb
  • -restoreToTime
    • <arg> Replay rodo logs until this time
      • Requires: --label or -lb
  • -restoreToRedoSeq
    • <arg> Replay up to and including this redo log sequence
Redolog Variables
  • --backedupRedologs or -br
    • Replays the redo logs in backup only, which excludes archived and current redo logs of the system
      • Only useful when restoring against latest full backup (NOT using the -lb option).
      • Will restore using incremental backup data after the last full backup as well but NOT including any redolog activity.
  • --restorefullBackup or -rf
    • Restores to the full backup only, not any incremental backups since that backup.
      • The default behavior of zmrestore in general is to always play from a "full" and "incrementals" that are associated with it UNLESS you state otherwise.
        • If you do:
          zmrestore -a mailto:user@domain.com -lb full6monthsago
        • It will playback the incremental data associated with that full from 6 months ago.
        • If you do:
          zmrestore -a mailto:user@domain.com -lb full6monthsago -rf
        • It will ONLY playback the data in the full from 6 months ago.
      • Will not progress past the data that's in the last full backup, no incremental backups after it in other words.
      • Implies NO redolog play, so there's no need to use -br.
Targets And Labels
  • --label or -lb
    • <arg> The label of the full backup to restore. Restores to the latest full backup if this is omitted.
  • --target or -t
    • <arg> Specifies the backup target location. The default is <zimbra_home>/backup.
Impact Of AutoGroup Option Being Used

Place for notes about how autogroup backup option might impact or limit command options.

zmbackup Options

Problems mostly revolve around these options:

  • --target or -t
    • <arg> Specifies the target backup location. The default is <zimbra_home>/backup.
  • --zip or -z
    • Zips email blobs in backup
Impact Of AutoGroup Option Being Used

Place for notes about how autogroup backup option might impact or limit command options.

Changing Default Backup Target

To find out what the current backup target is, do:

 zmprov gacf | grep zimbraBackupTarget
 zimbraBackupTarget: /opt/zimbra/backup

This is also configurable at the "server" level:

 zmprov gs `hostname` | grep zimbraBackupTarget
 zimbraBackupTarget: /opt/zimbra/backup

For example:

 zmprov ms `hostname` zimbraBackupTarget /san/mount/backup

Issues of changing the default path in regards to the admin web console. Please see:

Another way to change the backup path is described at Changing_Backup_directory_and_General_Information. I recommend reviewing it as well.

See Change Location For Backup Or Restore Source Data for non-default adjustments to CLI commands in regards to a non-default path for backups.

An Overview Of Some Backup/Restore Items

Remote copies of backup data for DR use

You will want to copy over /opt/zimbra/redolog/archive/* and /opt/zimbra/redolog/redo.log frequently in order to stay current. The redo.log file being open is not a problem since the crash recovery step can work with redo.log file in any state.

The redolog/archive/ contains logs that have not yet been backed up by an incremental (or by a full in auto-grouped mode)

The redo.log rolls over when it reaches zimbraRedoLogRolloverFileSizeKB (by default 100mb). When ZCS restarts after a crash, it seems to work through the current redo.log ok regardless of its state, if the current log really must be copied."

My Initial Thoughts On This

Start of process:

  • Weekend full on prod
  • rsync full-xxx on prod > remote sessions/
  • rsync redolog/* > remote redolog/
    • through non-full and incremental times every x about of minutes
  • weekday nights 10pm incre-xxx on prod
  • rsync incr-xxx on prod > remote sessions/
  • rsync redlog/* > remote redolog/

Created three separate rsync cron rules.

  • Full - once a week
    • Confirms full is done and then looks for latest full-xxxx and rsyncs that specific directory
  • Incre - once a night except for full schedule night
    • Confirms incre is done and then looks for latest incr-xxx and rsyncs that specific directory
  • Redolog/ - every x amount of minutes (outside of full and incr backups sessions)
    • Soes full rsync of redolog/ - probably want delete/remove option?
    • lsof will report /opt/zimbra/redolog/redo.log is open.

Somewhere we need to account for accounts.xml in this process. And also confirm what else might be missing. Also, steps on the actually restore process depending on when/where the DR event took place.

What's Needed For Later Restores

In regards to what is moved and what is needed for later restores, you must remember this "flow" of the backups:

  • Full backup files that contains all the information needed to restore mailboxes (to that point in time)
  • Incremental backup files that contains the LDAP directory server files and all the redo log transactions written since the last backup (to that point in time)
  • Redo logs that contains current and archived transactions processed by the Zimbra server since the last incremental backup (to that point in time - more about this topic is above)

Variables to be aware of in regards to backup/restore [ viewed with - zmprov gs [server-name] | grep Backup ]:

  • This is that gui path option - note, it doesn't change default to redo file path [see below]
zimbraBackupTarget

zimbraBackupMode
zimbraBackupAutoGroupedInterval
zimbraBackupAutoGroupedNumGroups
zimbraBackupAutoGroupedThrottled

zimbraBackupReportEmailSubjectPrefix
zimbraBackupReportEmailSender
zimbraBackupReportEmailRecipients
  • Variables to be aware of in regards to redo files [ viewed with - zmprov gs [server-name] | grep Redo ]:
zimbraRedoLogArchiveDir
zimbraRedoLogDeleteOnRollover
zimbraRedoLogEnabled
zimbraRedoLogFsyncIntervalslMS
zimbraRedoLogLogPath
zimbraRedoLogRolloverFileSizeKB

Restore Requires accounts.xml File

Change "Location" For Backup Or Restore Source Data

Remember that zmbackup and zmrestore can take flags as well in regards to the location of items.

  • zmrestore & zmbackup can both take : -t,--target (default <zimbra_home/backup)

You can't state a different location with redo logs though. There's a command called zmplayredo [for newer versions of ZCS] and it has a variable to point to the redologs to play from [ --logfiles ]. It will replay into the default redolog directory or redolog file. The mailbox has to be stop to run zmplayredo . This is a command to manual kick off a replay of a redo log. This is normally done with the zmrestore when options about to a specific time aren't included.

Manual Removal Of Older Backup Sessions

General Situation:

  • Keep in mind every restore requires starting with data from a full backup.
  • For each account on the server, there must be at least 1 full backup after the deletion is complete.
  • You should also make sure all incremental backups made after the oldest of the remaining backups are retained.
    • This basically gets reduced to deleting only those backups that are old enough, based on your full/incremental schedule.

More Specific Issues:

  • Does the accounts.xml dependency cause issues with this?
    • No. Just don't delete it.
  • What about the contents of the backup/tmp/ data or shared blobs type references?
    • Don't touch this directory either. It is used during backup and restore. You don't want to change its content while an operation is going on, so best to leave it alone.
  • What if a zimbra server is running some type of restore of backup command while the manual removal is running on the nfs server?
    • You shouldn't remove the backups that are being used in a restore currently underway. You are responsible for avoiding the race condition.
      • Please understand you are responsible for avoiding the race condition. Make sure no backup or restore is happening at the moment, then rename the directories that will be deleted, preferably move them to another subdirectory, e.g. /opt/zimbra/backup/sessions_to_delete. Then delete.

Redolog Files

Changing Redolog File Size

The redo.log rolls over when it reaches zimbraRedoLogRolloverFileSizeKB (by default 100mb).

zmplayredo - Replaying Content From Any Redolog File

zmplayredo is a newer command, first introduced in 5.0.5 I believe. The mailbox has to be stop to run zmplayredo.

The help output from 5.0.9:

[zimbra@mail3 ~]$ zmplayredo --help
usage: zmplayredo <options>
    --fromSeq <arg>         Replay from this redolog sequence (inclusive)
    --fromTime <arg>        Replay from this time (inclusive)
 -h,--help                  Show help (this output)
    --logfiles <arg>        Replay these logfiles, in order
    --mailboxId <arg>       Replay for this mailbox only
    --queueCapacity <arg>   Queue capacity per player thread; default=100
    --stopOnError           Stop replay on any error
    --threads <arg>         Number of parallel redo threads; default=50
    --toSeq <arg>           Replay to this redolog sequence (inclusive)
    --toTime <arg>          Replay to this time (inclusive)

Specify date/time in one of these formats:

    2008/09/29 14:17:27
    2008/09/29 14:17:27 029
    2008/09/29 14:17:27.029
    2008/09/29-14:17:27-029
    2008/09/29-14:17:27
    20080929.141727.029
    20080929.141727
    20080929141727029
    20080929141727

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.

Getting A Sequence or Time Variable For Restore Or Replay

You can see the changes within the redo logs with the command below. You can point it to any redolog.

zmjava com.zimbra.cs.redolog.util.RedoLogVerify /opt/zimbra/redolog/redo.log > out.file

You'll get output like this:

VERIFYING: redo.log
HEADER
------
sequence: 59
open: 1
filesize: 512
serverId: d5c5d6a7-b82f-4c29-b0cd-91818057196b
firstOpTstamp: 1222385426273
lastOpTstamp:  1222385426273
version: 1.22

------
txn 1222383600.1 [PurgeOldMessages] ver=1.22, tstamp=1222385426273, change=20200, mailbox=1
txn 1222383600.1 [CommitTxn] ver=1.22, tstamp=1222385426329, mailbox=1, txnType=PurgeOldMessages
txn 1222383600.2 [PurgeOldMessages] ver=1.22, tstamp=1222385486337, change=13500, mailbox=3
txn 1222383600.2 [CommitTxn] ver=1.22, tstamp=1222385486351, mailbox=3, txnType=PurgeOldMessages
txn 1222383600.3 [PurgeOldMessages] ver=1.22, tstamp=1222385546357, change=20201, mailbox=1
txn 1222383600.3 [CommitTxn] ver=1.22, tstamp=1222385546383, mailbox=1, txnType=PurgeOldMessages
txn 1222383600.4 [PurgeOldMessages] ver=1.22, tstamp=1222385606391, change=13501, mailbox=3
txn 1222383600.4 [CommitTxn] ver=1.22, tstamp=1222385606404, mailbox=3, txnType=PurgeOldMessages
txn 1222383600.5 [PurgeOldMessages] ver=1.22, tstamp=1222385666416, change=20202, mailbox=1
txn 1222383600.5 [CommitTxn] ver=1.22, tstamp=1222385666428, mailbox=1, txnType=PurgeOldMessages
txn 1222383600.6 [PurgeOldMessages] ver=1.22, tstamp=1222385726435, change=13502, mailbox=3
txn 1222383600.6 [CommitTxn] ver=1.22, tstamp=1222385726459, mailbox=3, txnType=PurgeOldMessages
txn 1222383600.7 [PurgeOldMessages] ver=1.22, tstamp=1222385786476, change=20203, mailbox=1
txn 1222383600.7 [CommitTxn] ver=1.22, tstamp=1222385786486, mailbox=1, txnType=PurgeOldMessages
txn 1222383600.8 [PurgeOldMessages] ver=1.22, tstamp=1222385846493, change=13503, mailbox=3
txn 1222383600.8 [CommitTxn] ver=1.22, tstamp=1222385846506, mailbox=3, txnType=PurgeOldMessages
txn 1222383600.9 [PurgeOldMessages] ver=1.22, tstamp=1222385906739, change=20204, mailbox=1
txn 1222383600.9 [CommitTxn] ver=1.22, tstamp=1222385906775, mailbox=1, txnType=PurgeOldMessages
txn 1222383600.10 [PurgeOldMessages] ver=1.22, tstamp=1222385966944, change=13504, mailbox=3
txn 1222383600.10 [CommitTxn] ver=1.22, tstamp=1222385966963, mailbox=3, txnType=PurgeOldMessages
txn 1222383600.11 [PurgeOldMessages] ver=1.22, tstamp=1222386026972, change=20205, mailbox=1
txn 1222383600.11 [CommitTxn] ver=1.22, tstamp=1222386026990, mailbox=1, txnType=PurgeOldMessages
...

How Do I Figure Out Which Sequence or Time Variable To Use For Restore Or Replay

To locate the correct restore-to time, you have to start with an approximate time the message was added/deleted. Look at the redolog files. The filename contains the GMT time when the file was rolled over, which is roughly the tstamp of the last operation in the file. If your time data is accurate you can find the specific file. Or you have a range of files to examine.

Use the redolog verify tool to dump the contents into text form, the -m / --message option to show message body data:

zmjava com.zimbra.cs.redolog.util.RedoLogVerify -m <filename or directory> ... > out.file

If the message was deleted and you don't know the id, you must go by some other clue such as the subject. Search the file to locate your message. You can cut/paste the message and lmtp-inject it to recover the message. No need to go through with a restore if this is all you needed.

In 5.0.10 we'll have a CLI wrapper (zmredodump) with a slightly different command line syntax, but the above long syntax works in earlier versions.

Gap In Redo Log

The error message from either a backup or restore command:

"Error occurred: Found gap in redo log sequence; missing 5965 through 6149;
To avoid future restore problems, discard all existing backups and take a
full backup of all accounts; If this error occurred during restore,
try the --ignoreRedoErrors option"

The output is pretty accurate in how to handle the situation.

If you get the error during a backup, the recommendation is to move your old backups out. The directories in /opt/zimbra/backup/sessions/* . You'll want to keep them around just in case and then proceed to do a full backup.

If you get the error during a restore, you would add the flag --ignoreRedoErrors to your restore command.

Another possible related issue is if your /tmp or /opt/zimbra/redolog/ is filling up.

Issues After /opt/zimbra/backup Became Full

You can run into numerous issues if you allow your backup directory to become full.

Confirm your /opt/zimbra/backup/accounts.xml is being updated after a backup. You might see that the newer account.xml* file is accounts.xml.new . This is a sign of problems.

Confirm that the files in /opt/zimbra/backup/tmp/* don't have 0 byte lengths. There might be files like 1.xml and 3.xml in there. If they show 0 bytes, you need to remove them. The backup/restore commands if the file exist and they are empty. Your errors might look like this:

[zimbra@mailb ~]$ zmrestore -a USER@DOMAIN -ca -pre restore_
Error occurred: system failure: Unable to parse XML file /opt/zimbra/backup/tmp/restore/shared_blobs/1.xml

If you tried doing restores (redirected -ca -pre) before to clear up the above issues, you might find you can't do a successful restore AND you can't delete the account afterwards.

If you get errors like :

zmprov da mailto:restore3_tester3@mnstate.edu
ERROR: service.FAILURE (system failure: writing new mailbox row for account 89e7d9f4-013e-4cf1-a352-7b2f0a00d5af)

zmprov gmi restored_USER
ERROR: service.FAILURE (system failure: writing new mailbox row for account 56a7f654-f85b-45cc-931a-81d9bb9076bf)

You'll need to delete the account via a ldapdelete command.

Stopping A Backup or Restore In Progress

Please see url below for Backup In Progress - topic name "Aborting Full Backup In Progress":

  • A matter of using zmbackupquery & zmbackupabort .

Please see url below for Restore In Progress - topic name "Stopping a Restore Process" :

  • A matter of using zmbackupabort -r .

http://www.zimbra.com/docs/ne/4.5.10/administration_guide/10_Backup_Restore.13.1.html#1042283

Restore To Time Problems

There's seems to be some syntax issues when using this variable. Please review the following to confirm your syntax.

http://wiki.zimbra.com/index.php?title=CLI_zmrestore_restoreToTime_Network_Edition_only

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.

Example:

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:

Restore Account Not Yet In Backups

Please see:

How To Restore To Events Within The Same Day

Work in progress and investigation.

Users Trash Items

User Ability To Recover Trash Purge

Please see RFE:

Retention Policy About Purges

Please see Mailbox_Purge

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

zmprov gac

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

To confirm

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

Restore Of Non-Account Items - Example - COS DL Etc

Cos and DL's are ldap entries basically.

From Network_Edition_Backup_Procedure

  • zmrestoreldap. This command restores the complete LDAP directory server, including accounts, domains, servers, COS and other data."

You'll see in a DR process, Network_Edition_Disaster_Recovery , that the zmrestoreldap is done before the zmrestoreoffline .

  • zmrestoreldap doesn't have options that allow specific items to be restored (COS, DL's, etc.). It only has option for named accounts (-a). One could try a ldapadd with a ldif of the COS or DL details. One could also take the information on the COS or DL within the ldap file in the backup session to at least have all the variables to manually add it back (via the zmprov command). Your looking at the backups on the LDAP master if your in a multi-server configuration.
/opt/zimbra/backup/sessions/full-xxxxxx/ldap/ldap.bak

Start of ldap entry example to search for:

  • Cos example
    • dn: cn=default,cn=cos,cn=zimbra
  • DL example
    • dn: uid=dl-group,ou=people,dc=mail,dc=domain,dc=com

To compare a current DL with past details, just save out the ldap entry from the backup to a txt file. And then do:

zmprov gdl maillist@domain.com

Make the necessary changes after comparing the two.

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 user@domain.com gru /Calendar > /tmp/calendarA.ics
     zmmailbox -z -m restore_user@domain.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 user@domain.com 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 user@domain.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 user@domain.com 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

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 ajcody@mail3.internal.homeunix.com ef /Calendar
* ef is for emptyFolder  zmmailbox help folder
*webclient shows all events gone but Calendars are still listed.
zmmailbox -z -v -m ajcody@mail3.internal.homeunix.com pru /Calendar /tmp/calendarB.ics
*webclient show all events with times as expected.

Second Fix

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.

Jump to: navigation, search