建议加强备份恢复这块

今天一天，上午在发帖子，大概20个左右，花了4个多小时，因为每个帖子图片有30-60个，而且文章还是翻译的，另外还有图片链接，几本上全是手工处理的，所以非常的辛苦。下午备份恢复，失败，后来折腾半个小时，只能把昨天的备份恢复，网站总不能打不开吧，把数据库下载后，在本地环境进行重新安装恢复，结果照样失败，原来数据库备份就米有完整，备份了15个表，但恢复的数据库大小只有7.49M，偶之前好像20M多了，这明显是备份不完整造成的，所以怪不得恢复也造成全部帖子丢失。米想到1天时间就这样折腾过去。
话说回来，数据库备份这块，偶已经第6次出问题，而且专门看了教程才操作的，最近经验也不少，但还是难以避免出现问题，建议官方能够在数据库备份时，增加检验机制，防止备份的数据库不完整或损坏，从根本上解决恢复失败的问题。不知道偶提的建议是不是对的，但偶希望在备份恢复数据库这块能够不花这多时间，因为时间是很宝贵的。{:soso_e140:}

数据库备份这块，偶已经第6次出问题，而且专门看了教程才操作的

我的很少出问题阿 访问量很大么

直接导出数据库啊  ==

一般用Phpmyadmin+文件拷贝就可以很好备份了，很多大站子一般也是这样做备份的。有的就直接给整台服务器磁盘文件做备份镜像了，怎么都比用DZ自带的好。

我几年前，就始终不明白这个问题，DZ自己里面做备份功能干什么，一个本身功能就受限，另外一个不有点多余吗。PMA做的都很好，直接就整站打包走了，很方便。

没备份 就完蛋了！

有备份不完整，也完了。{:soso_e127:}

嗯嗯。楼主分享的不错。

楼主分享的不错。

sw08 发表于 2012-6-10 14:10
一般用Phpmyadmin+文件拷贝就可以很好备份了，很多大站子一般也是这样做备份的。有的就直接给整台服务器磁盘 ...

是啊，一个 tar 把整个目录备份即可，如果为了稳妥可以停掉mysql再做。
dz自带的备份可以针对表来备份恢复，这是相当容易产生数据逻辑错误的，尤其是对members/threads/posts这三个表的单独操作。

另外，Phpmyadmin备份出来的sql格式好像是每条insert的，恢复速度比copy差远了（超过10倍）。我宁愿mysql_dump也不用它。

sw08 发表于 2012-6-10 14:10
一般用Phpmyadmin+文件拷贝就可以很好备份了，很多大站子一般也是这样做备份的。有的就直接给整台服务器磁盘 ...

几百M的MySQL，有很多恢复不了的。