avamar maintenace obecne 2. – checkpoint
- čekpoint je read-only snapshot stavu avamaru a jeho dat. Čekpoint sa robí 2x denne, na začiatku a konci maintenance okna.
- čekpointy su storované na datanodoch v adresároch s názvom napr. cp.20180901054452 – year, month, day, time
- ako vylistovat checkpointy – cplist
- ako obnovit stav dát k určitému čekpointu – rollback.dpn –cptag=cp.XXXXXXXX (číslo čekpointu; cp.YYYYMMDDHHMMSS)
- suspendování scheduleru čekpointu (aby se automaticky nespustil) – avmaint sched suspend cp –ava
- opetovné povolenie scheduleru pre čekpoint – avmaint sched resume cp –ava
- manuálne vytvorenie čekpointu – avmaint checkpoint –ava
- ako avamar_checkpoint_DD, ak avamar ľahne
- Pokial CP zisti krute chyby na datach, vypise alerty do MCkonzole a logu. Tieto alerty maju zvlastnu vlastnost, ze sa nedaju vymazat (MCkonzola – acknowledge alerts), len po zadani specialneho helsl aod EMC. Niekedy je to opruz, lebo nove CP su uz v poriadku a stare nie, takze stale svietia stare alerty, ktore clovek moze v pohode odmazat, tudiz tu komand s generickym heslom: mccli event clear-data-integrity-alerts –reset-code=AVAMARDATAOK
Here is sample output from the command ‘cplist’
cp.20130915110057 Sun Sep 15 12:00:57 2013 valid rol — nodes 3/3 stripes 3530
cp.20130915110654 Sun Sep 15 12:06:54 2013 valid — — nodes 3/3 stripes 3530
We will look at the first checkpoint listed in the output and discuss, left to right, the meaning of each data field.
Checkpoint tag name – cp.20130915110057
This is the identification tag for the checkpoint and corresponds to the time the checkpoint was started. cp.YYYYMMDDHHMMSS
Note that from Avamar v7.1, checkpoints will be assigned with serial numbers instead of being tagged with the checkpoint start date and time.
Time taken – Sun Sep 15 12:00:57
The day, date, and time when the checkpoint was created. This will always correspond with the checkpoint tag.
Validity – valid
If this field shows ‘valid’ it means that the checkpoint is ‘wholesome’. In this context, validity denotes whether the checkpoint can be used for rollback purposes. If this field shows ‘valid’ It does not mean that the checkpoint has undergone HFScheck validation. This is a very common misconception. The validity field is actually superfluous when running “cplist” since by default the command will only show usable checkpoints. Running “cplist –full” will show all checkpoints on the system, including any which are not usable for rollback purposes.
HFScheck validation type – “rol”
This field will show the type of HFScheck validation which has checked on the checkpoint. Possible types are ‘hfs’, ‘rdc’, ‘par’, ‘rol’
hfs or full – means that validation has checked on all stripes in the checkpoint.
roll – means that a validation has checked on (at least) all new or modified stripes in the checkpoint. Research by Avamar Engineering has found that when data integrity issues occur, in the vast majority of cases the affected stripes are those which are newly created or recently modified. Given these findings, Avamar engineering recommend that rolling validation be considered to be practically as reliable as the traditional, and much lengthier full HFScheck validation. Note, depending on the Avamar system s rate of data changeingestion rate, a rolling HFSchecks may also check a proportion of a checkpoint s unmodified stripes, meaning that over a period of time, all stripes, even those which have not modified, may be integrity checked.
rdc – means that validation has been completed but that one node did not participate in the validation. Validation type is not specified. Note that the integrity of the data cannot be guaranteed for checkpoints tagged as rdc , however such a check provides better confidence in the data integrity than no validation at all.
Deletable “—”
This field indicates whether the checkpoint is deletable, according to checkpoint retention settings currently in force on the Avamar server.
Checkpoint retention is controlled by the “cphfschecked” and “cpmostrecent” parameters. Checkpoint retention should be left as default unless advised by a qualified EMC support professional. Incorrect checkpoint retention settings can put an Avamar system at risk of data loss, or can cause OS capacity issues.
REFCOUNT / NODECOUNT – “node 3/3”
The first number is the refcount and reports the number of nodes that responded to the cplist command. This value does not necessarily mean the number of nodes which are currently online.
The second number is the nodecount. This refers to the number of nodes which participated when the checkpoint was originally taken, in other words, how many data nodes contain that particular checkpoint directory.
Care should be taken to note the state of the system (number of total nodes and number of nodes online) and how cplist was run before contemplating the meaning of the output of these two fields.
Stripe count field – “3530”
This field displays the total number of stripes captured in the checkpoint. A rolling checkpoint validation will validate a subset of this number of stripes. A full checkpoint validation will validate all of them.
ďobo
4 Oct 18 at 17:05
[…] – v jeho terminológii “checkpointy”. Defaultne 2x denne a stará sa o to utilita checkpoint. Pokiaľ avamar zálohuje do DD, tak tieto checkpointy tiež ukladá na DD. Tiež štandardne […]
Avamar – chyby expirácie snapshotov na DD at db.dobo.sk
29 Mar 19 at 13:46