This post is more than 5 years old
1 Rookie
•
43 Posts
0
1742
September 26th, 2016 03:00
Equallogic V7.1.5 intermediate snapshots
Hello,
i examined how EQL snapshots work (AoW), and think to have understood that snapshots are child only to their base volume. Nevertheless, they just store the modifications in relation to the previous snapshot...
That's why i'm in doubt it would o.k. to delete intermediate snapshots?
The system let me do so, but now i receive [ID: 4.18] ...
Could someone please elaborate on this?
Thanks in advance
No Events found!
HifDelCo
1 Rookie
•
43 Posts
0
September 26th, 2016 05:00
Hello Don,
thank your for helping so quick.
If i got that right, the additional pages for the modifications reside on the base volume in the snapshot reserve, while the snapshots just keep the pointers to tha respective pages?
The entire message i now face reads like:
"[ID: 4.18] Schedule XYZ for volume XYZ has fewer than expected snapshots. Expected 70, but the volume only has 38. Condition already generated an e-mail message. If the condition persists, additional messages will be sent approximately every 6 hours."
... for each volume i removed intermediate snapshots for.
I resorted to that approach since we need current snapshots to be made, but run out of capacity at the same time, which is why we can't raise the reserve anymore.
And we can#t allow the policy to delete the oldest snapshots as the oldest 5 snapshots are still crucial for us...
A bit messy, but in the context of bridging a migration process.
Regards,
H.
HifDelCo
1 Rookie
•
43 Posts
0
September 26th, 2016 08:00
Hello Don,
thank you very much for making this clear.
I'd liked to have cloned those snapshots, as this seems to be the proper way to handle such an interest, but the total space reserve won't be sufficient for this.
I'll check whether establishing a substituting new snapshot policy will stop the [ID: 4.18] from showing up.
Best regards,
H.
HifDelCo
1 Rookie
•
43 Posts
0
September 26th, 2016 08:00
Hello Don,
thank you again!
@"The snapshot reserve is where the original data resides,"
Ahh, i considered that the snapshot reserve might *not* be a block area different from the basevolume...
So the base volume stays untouched, when i create the first initial snapshot, i guess?
And that reserved area is *in*dependent from the first snapshot, it's just allocated upon creating the initial snapshot; i.e.: i safely can delete the first initial snapshot, but the reserved area will still survive, right?
@"Re: error message. That's a normal message given that you are deleting some and some are rolling off from space constraints it sounds like. "
This is what i'm slightly concerned with: it looks like the system was totally fine with me removing intermediate snaphots (no warning, no hints, ...), but now it looks like the system is missing some of them. Since the total count of snapshots now is effectivley well below the critical barrier once configured in the snapshot policy, indicating where to start deleting the oldest snapshots, it will hopefully not blindly follow that policy on base of the assumption, that it just can't find all of the snapshots it expects to be present?
Because this i my primary concern right now: keeping those old snapshots at any cost...
And: is there any means of recalibrating that "expectation"?
For the time being i tried with deactivating the snapshot policy and reactivating it immediately afterwards, but am not sure whether that helped getting rid of the error message.
Best regards,
H.