How do I create a backup before making changes?

Two layers of backup

1. Version history (inside Lovable). Before making a risky change (a big prompt, a schema migration, an experimental feature), open Version history and bookmark the current state. If the change goes wrong, you can revert to that exact bookmarked point in a couple of clicks.
2. GitHub (outside Lovable). If Git sync is connected, the current code is already pushed as a commit — a copy that exists independently of your Lovable account. If it isn't connected yet, connect it now; this is the single best "insurance policy" for a project you care about.

Before we make this change, bookmark the current version so I can easily revert if anything breaks.

For database changes specifically

Schema and data changes aren't automatically covered by code version history. Ask Lovable to describe what a migration will do before running it, and for anything destructive (dropping a column, deleting rows), ask for a safer alternative first (e.g. renaming/hiding rather than deleting) if you're not confident it's reversible.

Quick pre-change checklist

• Bookmark the current version.
• Confirm GitHub sync is connected and up to date (or connect it now).
• For database changes, ask Lovable exactly what will change and whether it's reversible.
• Make one significant change at a time rather than bundling several risky changes into one prompt, so a revert doesn't undo unrelated good work too.

What usually goes wrong

• Only relying on auto-versions and not bookmarking, then struggling to find the right point among many small auto-saved versions later.
• Assuming Version history covers database contents the same way it covers code — it doesn't; data changes need their own care.
• Never connecting GitHub, so there's no copy of the code independent of the Lovable account.

See also should I connect my Lovable project to GitHub for the bigger-picture backup argument.