Все, что есть в базе, можно разделить на три вещи.
1) Структура базы. Определяется миграциями. Например:
Doctrine Migrations,
Laravel Migrations,
PhpMig. В принципе, все реализции похожи: есть набор миграций, в имени которых содержится timestamp их создания, по которому они упорядочены. Как правило, это php-класс с методами up (применить миграцию) и down (откатить миграцию). При этом где-то хранится список примененных миграций (например, в табличке migrations).
2) "Системные" данные, которые надо инициализировать сразу после создания базы (например, какой-нибудь изначальный набор категорий товаров в магазине). Сюда же тестовые данные, которые удобно записать в базу для разработки или для запуска интеграционных тестов. Процесс записи этих данные в базу называется database seeding; seeder - это просто какой-нибудь класс, который данные пишет. В контексте тестов ровно то же самое называется data fixtures. Например:
Laravel Database Seeding,
Doctrine Data Fixtures. Может быть реализовано просто как классы и cli-скрипт для их запуска.
3) Собственно, все остальные данные, которые появляются в результате работы приложения, в основном на продакшене (девел/тест-данные ценности не представляют). Базу надо бэкапить. Работать с production-базой в devel-среде не надо. Если кажется, что надо, все равно не надо (например, если при определенном наборе данных проявляется какой-то баг, надо написать тест, который его воспроизводит). Если случилось так, что все-таки надо, всегда можно взять дамп из бэкапа production-базы (который, разумеется, делается регулярно), сделать, что хотел, и вернуть все как было.
