How to Plan for Unplanned Absences
People get sick, scope changes, and stuff happens. That's why velocity should always be measured as an average or a range, and primarily used as an upper bound on work selected for a Sprint rather than a target.
If you have sufficient slack in your Sprint Planning, a couple of sick days will not put your Sprint at risk. However, if you've stuffed your Sprint to the gills with work, you may or may not have a problem depending on whether the team has sufficient remaining capacity to meet the Sprint Goal.
Focus on the Sprint Goal
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
The question is whether the team can still meet the Sprint Goal. The only way to find out is to ask them, and then track progress toward the Sprint Goal in your burn-down chart, Kanban board, Sprint Backlog, or other artifacts.
With sufficient slack and a cross-functional team, a well-planned Sprint will still be able to reach the Sprint Goal. However, if the team is not confident about reaching the goal with an absent team mate, then the Product Owner should be consulted. The Product Owner has the ability to renegotiate scope for the Sprint, or to cancel the Sprint and return to Sprint Planning, whenever the current Sprint Goal is at risk.
How This is Reflected in a Burn-Down Chart
Your burn-down shouldn't change, because the Sprint Goal doesn't change just because the team's capacity does. What will change is your burn-down's trend line, which is as it should be. This is transparency in action!
Only change your burn-down chart to reflect Sprint Backlog Items added or removed from the Sprint Backlog. If the team determines that Sprint Backlog Items can be removed from the Sprint without endangering the Sprint Goal, then the work remaining in the Sprint will change accordingly.
In practice, you don't revise the entire burn-down chart. The removed work shows as a sudden drop in the x-axis at the time the work is removed from the backlog, but you wouldn't retcon the chart. Changes in the x-axis are normal in Sprints, as work may be added or removed from the Sprint Backlog throughout the iteration as tasks are uncovered through just-in-time planning, or as efficiencies are discovered or implemented.