How do people practice scrum when working in a small team that creates features but is also supporting the product and have to do unplanned support tasks. How can I protect my burndown chart?Saving Changes...

You'd can't protect your burndown chart in that situation. A Scrum team is supposed to be insulated from outside interference such as performing support tasks; each support task you do robs you of time available do work on your sprint.
I'm in a similar situation, where my team does development work and support tasks. I have to make my Management understand that every support task we do detracts from our ability to do development work. They don't want to hear that, but that's the reality of the situation. When we receive support work I promptly let Management and customers know how much it will lessen our ability to produce development work; that's the best I can do under the circumstances.Saving Changes...

Rather than protect it, showcase it. Rather than protect the protect the burdown, the SM should protect the team. Transparency! I&A!
Ideally, there should be no unplanned support tasks. Those items go into the backlog and pulled into the sprint backlog as needed based on priority. As the team(s) mature with story writing, execution, testing (and automated), CICD, support tasks should decrease dramatically.Saving Changes...

After reading Andrew's reply I realize I might have misinterpreted your initial question. I assumed the support tasks you mentioned were external to your development activities, such as helping out when an application unexpectedly goes down). Is this the case, or are the support activities you perform part of your development activities?Saving Changes...

If this support work relates to the product and the team is 100% dedicated to that product, then their backlog should include both development and support work items. You'd likely have a product backlog which might only reflect the development work items.

The team's burndown chart would show the progress in completing all work items whereas a product burndown/burnup chart or version report (a la JIRA) would be focused only on the development work items.

The problem with that situations is do not take into account that develop must be manage in a separete way than maintenance. Both are totally different process and not matter the approach you use. What I mean is not physical separation or team separation. What I mean is to manage them two different process (or things inside the process) must be taken into account.Saving Changes...