Symantec 10744983 Administration Guide - Page 216

Backing up logs data, Backing up the Spam and Virus Quarantine databases

Page 216 highlights

216 Administering the system Periodic system maintenance Backing up logs data In general, there is no reason to store stale logs. For troubleshooting purposes, logs that are not set to Information or Debug (which provides the most detail) have limited utility, especially if you need assistance from Symantec Support personnel. It is best to view and save current logs as needed on the Logs page and set the appropriate retention period for logging data. Backing up the Spam and Virus Quarantine databases The messages in Spam and Virus Quarantines are stored in MySQL databases. You can back up the Spam and Virus Quarantine databases together, using MySQL. Or you can backup each database separately. If you have a large number of messages in Spam Quarantine, backing up may take some time. Backups can be done while the Symantec software is running. MySQL must be running when you perform backups. For complete instructions on performing backups of MySQL data, see MySQL documentation. The following MySQL commands are suggested for your use. The metadata for suspect virus messages is stored in MySQL. The actual suspect virus messages are stored in a directory, not in MySQL. The metadata in MySQL and the separate directory must be backed up and restored individually. Note: In the instructions in this section, replace the value PASSWORD with the following text on Solaris or Linux: `cat /opt/Symantec/SMSSMTP/.brightmailuser` On Windows, open the following file in a text editing application and use the file contents as the value of PASSWORD: C:\Program Files\Symantec\SMSSMTP\.brightmailuser Back up and restore Quarantine database information Use the following procedures for backing up or restoring quarantine databases.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249

Backing up logs data
In general, there is no reason to store stale logs. For troubleshooting purposes,
logs that are not set to Information or Debug (which provides the most detail)
have limited utility, especially if you need assistance from Symantec Support
personnel. It is best to view and save current logs as needed on the Logs page and
set the appropriate retention period for logging data.
Backing up the Spam and Virus Quarantine databases
The messages in Spam and Virus Quarantines are stored in MySQL databases.
You can back up the Spam and Virus Quarantine databases together, using MySQL.
Or you can backup each database separately. If you have a large number of
messages in Spam Quarantine, backing up may take some time.
Backups can be done while the Symantec software is running. MySQL must be
running when you perform backups. For complete instructions on performing
backups of MySQL data, see MySQL documentation. The following MySQL
commands are suggested for your use.
The metadata for suspect virus messages is stored in MySQL. The actual suspect
virus messages are stored in a directory, not in MySQL. The metadata in MySQL
and the separate directory must be backed up and restored individually.
Note:
In the instructions in this section, replace the value
PASSWORD
with the
following text on Solaris or Linux:
`cat /opt/Symantec/SMSSMTP/.brightmailuser`
On Windows, open the following file in a text editing application and use the file
contents as the value of
PASSWORD
:
C:\Program Files\Symantec\SMSSMTP\.brightmailuser
Back up and restore Quarantine database information
Use the following procedures for backing up or restoring quarantine databases.
Administering the system
Periodic system maintenance
216