Я удалил производственную базу данных в пятницу вечером ( vince.beehiiv.com )
Не знаю. Усилия, необходимые для обеспечения резервного копирования, ничтожны по сравнению с работой, проделанной для создания продукта. А чтобы сделать резервную копию перед удалением чего-либо в производстве, требуется лишь немного опыта.
Им невероятно повезло. Представьте, что сказал бы босс, если бы им не удалось восстановить данные.
Я удалил производственную базу данных при первом запуске, над которым работал, через три дня после того, как мы начали работать. Мы были scrappy™ и у нас еще не было резервных копий, поэтому мы потеряли все данные навсегда. В тот день я узнал, что запуск автоматизированных тестов в производственной базе данных — не очень хорошая идея!
Я испытываю глубокую боль и тоску за тебя и всех, кто в этом участвовал. Эти уроки так больно усваивать на собственном горьком опыте.
Фраза «и честно?» попахивает написанием искусственного интеллекта до такой степени, что я остановился на этом и закрыл пост.
Не хрен с базой данных и делай откаты на определенный момент времени. Никаких оправданий, это не сложно. Не то, чем можно гордиться.
Надеюсь, автор поста в какой-то момент узнает о транзакциях. Postgres даже позволяет изменять схему внутри транзакции.
Когда-то давно я узнал, что в базе данных не следует удалять данные, которые вы хотите сохранить. Если вы хотите что-то сохранить, вы используете прекрасную функцию SQL UPDATE, чтобы обновить это, а не удалять. Базы данных работают лучше всего, если вы говорите им делать то, что вы хотите, как одну транзакцию.
Если предположить, что стоимость хранения не имеет большого значения, я большой поклонник мягкого удаления везде. Также оставляет легкий «аудиторский след», чтобы увидеть, кто пытался что-то удалить.
Конечно, есть исключения (правила удаления GDPR и т. д.)
Я однажды удалил базу данных разработчиков в PayPal еще в 2006 году.
Source: news.ycombinator.com