这是一个创建于 1191 天前的主题，其中的信息可能已经有所发展或是发生改变。
提个醒：
1.一定要做数据库自动备份，至少每日一备份。 就是个脚本的事情，搜一下就完事了。
2.除了查询外，做增删改之前，一定要备份一次。不要怕麻烦，不要怕耽误时间。 性能不够上固态，固态不够上内存盘。
以上两点，没做好，是有可能吃牢饭的，没开玩笑。
 | 1 zhzy0077 2022-07-11 20:06:24 +08:00 via Android 所有 dml/ddl 前要么 begin transaction 要么找人 review 一遍也很重要 |
 | 3 moult 2022-07-11 21:10:52 +08:00 3 、不想动手就掏钱买云数据库吧，都有秒级回滚功能。 |
 | 4 rekulas 2022-07-11 21:17:20 +08:00 提到的 2 点没意见，最后一句不敢苟同，似乎没有过这种案例吧 |
 | 5 kingjpa 2022-07-11 22:16:10 +08:00 自己玩的项目还好， 生产数据库备份一次要多久，以及会不会锁表，没试过吗？ |
 | 6 cpstar 2022-07-11 22:26:27 +08:00  1 我倒是没有删库，就是 update 的时候忘了 where ，而已，而已，而已。。。多大点事 |
 | 7 shench 2022-07-12 03:00:41 +08:00 有些软件不小心对某个表按了一下 del 键，一会儿运行的时候这个表就这么没了。。。。我碰到过两次 |
 | 8 ktqFDx9m2Bvfq3y4 2022-07-12 07:44:00 +08:00 via iPhone 数据是最宝贵的，我选择使用云上的服务，回滚到任意秒没什么压力。其他可以自己搞。 |
 | 10 luckyc 2022-07-12 08:22:11 +08:00 总结的不错, 刚入行的新手可以看看. 老手就一笑而过了. |
 | 11 micean 2022-07-12 08:27:55 +08:00 动生产库养成建表存变动数据的习惯 |
| 13 ktqFDx9m2Bvfq3y4 2022-07-12 08:40:53 +08:00 via iPhone @xubingok 不需要时时备份，mysql 云数据库定时备份binlog ，可以恢复到任意时刻。云商自带功能。 |
 | 14 hay0577 2022-07-12 09:00:05 +08:00 .....垃圾项目表很大了咋办.. |
 | 15 ila 2022-07-12 09:04:07 +08:00 via Android 克隆个 dev 数据库，放脱敏后的数据，操作无误，再用同个语句操作线上的 |
 | 16 liuliangyz 2022-07-12 09:06:58 +08:00 1 说明，你们这些系统基本都不是特别重要的系统。重要的系统不回搞什么脚本备份的，肯定是上数据库集群，硬件上就是多机热备，共享存储。同时存储也是硬件灾备。 什么软件热备，手工备份，都是为了省成本高出来的软件方案。 |
 | 17 morty0 2022-07-12 09:15:40 +08:00 3. 手动 commit |
 | 18 zhw2590582 2022-07-12 09:18:38 +08:00 1 我就没有这种烦恼，因为我是前端 |
 | 19 jorneyr 2022-07-12 09:21:48 +08:00 阶段全备，每日增备 |
 | 20 singerll 2022-07-12 09:32:43 +08:00 性能不够上固态，固态不够上内存盘。 抱歉，就是 dba ，我也没见有这么大权力的。 |
 | 21 Cmdhelp 2022-07-12 09:33:27 +08:00 做好数据备份，真的很重要 |
 | 22 R18 2022-07-12 09:35:00 +08:00 我有点好奇, 200 多 G 的数据库该怎么备份. |
 | 23 mywaiting 2022-07-12 09:42:13 +08:00 OP 没有总结到点上啊，备份肯定没错，但备份只是挽救措施 最关键的是：永远不要手动执行 SQL 语句~ |
 | 24 vone 2022-07-12 09:44:33 +08:00 |
 | 25 nothingistrue 2022-07-12 09:52:19 +08:00 这两个提醒属于费工夫不讨好的提醒。 用在生产库上没用：1 ，这种备份作用很有限，一天一备份间隔时间太长，热机备份不能直接用来恢复，冷机备份又要先停机； 2 ，啥都备份等于啥都没备份，这种备份压根没法用来恢复数据。 用在个人库徒增工作量。 对于在程序之外动生产库的操作，一减少二增加操作审查流程，要比上面的方式有效多了。 |
 | 27 xdzhang 2022-07-12 10:27:05 +08:00 数据随时都在变，不实时你的备份有啥用。。。 |
 | 28 agdhole 2022-07-12 10:29:20 +08:00 rds 多机自动备份，充钱世界可及 |
 | 29 liuidetmks 2022-07-12 11:08:08 +08:00 @shench 什么破软件？，不过应该权限没设置好是根本原因吧 |
 | 30 woostundy 2022-07-12 11:09:04 +08:00 不可能，备份也是资源消耗。 |
 | 32 Zach369 2022-07-12 14:31:55 +08:00 主从,集群.... |
 | 33 fangdaidai 2022-07-12 16:37:48 +08:00 @rekulas 破坏计算机信息系统罪了解下 |
 | 34 Tounea 2022-07-12 16:49:36 +08:00 想问下各位数据库备份频率是怎么样的？是每天增备还是每天全备？数据库小还好说，要是数据库容量特别大呢？ |
 | 35 adoal 2022-07-12 16:57:17 +08:00 @xdzhang 有实时备份可以完整恢复当然好，但如果数据被破坏了又没办法完整恢复回来，要承担经济甚至法律责任时，丢失一天的数据跟跟全丢的责任轻重还是大不一样的，这时候有 daily backup 对当事人来说当然有用 |
 | 36 neptuno 2022-07-12 17:17:56 +08:00 1 、测试环境多测试几遍 sql 2 、线上运行前，找人 review 。（站内那几个案例，感觉都是连测试都没测过，直接线上手写 sql ，肯定会出问题） |
 | 37 james2013 2022-07-12 17:55:16 +08:00 理论上备份是好的 实际使用时,生产库表的数据很多,有的表 1 张都很大,备份一次时间都不知道要多久呢,要是多改几次数据,1 天就没有了,哪里这么规范呢 |
| 38 rekulas 2022-07-12 18:00:54 +08:00 |
| 39 rekulas 2022-07-12 18:21:13 +08:00 另外就算是不小心删库导致的事故，目前暂时也未看到判决案例，目前看到的基本都是主观破坏性删除定罪的。 对于非主观事故，可能也有责任但不清楚该适用什么罪，玩忽职守罪肯定不对那是机关工作的 |
| 40 xdzhang 2022-07-13 08:07:13 +08:00 @adoal 最初的时候我也是每天备份一次，后来发现不行，没多大保障，又快照，发现快照还是不行，现在我做实时备份。主要清理起来真的太恼火了，也不是说前面的不行，也是必须做的，尽量减少损失。 |
 | 41 awen233333 2022-07-13 08:12:26 +08:00 update 或 delete 的时候加个 top 或者 limit 限制要更新的数量，并将要更新的那几行数据备份，Oracle 手动 commit |
| 42 vone 2022-07-13 09:17:47 +08:00 @rekulas 仔细看链接哈，那人是运维，在系统出现生产问题后，尝试使用私下开发的运维程序处理问题导致的事故。 他被认为主观的原因是：1 、私自使用未经授权的管理员账号； 2 、事故后使用 360 安全卫士清理过软件垃圾和软件使用痕迹（被认为是隐瞒犯罪事实）。 |
 | 43 yc8332 2022-07-13 09:36:07 +08:00 你怕是没见过大生产数据库吧。知道备份一次要多久吗？根本做不到 1 日 1 备份。。都是几天 1 备，有问题时间近的用 binlog 恢复。 |
Select Language