一、背景
2009-11-19日下午约17：00开始，出走社所租用的位于上海移动机房的虚拟主机连同机房内其他数千台服务器一起被不明身份的匪徒强令以查备案为名封禁IP，其间11月22日23：00至11月25日18：00曾短期恢复，此后便处于长期封禁状态，代理我社主机租用业务的湖北巨盈公司交涉无力，解封遥遥无期，并且据悉在中国内地其他地区、其他机房也开始了非法大量随意封禁服务器的运动。为了继续我们的社区生活，从根本上防止类似丑剧在我社身上重演，不得不采取壮士断腕的措施，我租用了香港虚拟主机，并就不再等待上海主机恢复立即启用香港主机的议题，在我社临时栖身的豆瓣出走社小组发起了表决，以目前的表决形势来看，在规定期限内，提案通过的可能性极大，为了安排启用新主机后的数据重建工作，我对网站程序做了修改，并提前写了这份备忘录，一旦启用香港主机，可立即指导数据重建工作。
二、重建数据的原因：
在上海主机被封禁之前的2009-11-13 7：35，我备份过一次数据库，因此，在香港主机上保留的数据不晚于这个时间。此后，我社产生的数据，绝大部分存储在上海主机上，小部分寄存在豆瓣上。香港主机启用后，为了保证历史记录的完整和我社社会生活的继续，必须对遗失在上海主机上和寄存在豆瓣上的数据进行重建，鉴于上海主机的恢复遥遥无期，我们不可能等到上海主机恢复后再将原始数据恢复到香港主机上，而且由于技术原因，即使上海主机将来恢复了，其上面的数据也不可能无缝拼接到香港主机上。因此，这里的数据重建在很大程度上是重新发布，甚至是重新撰写，这个任务是很艰巨的。
三、任务和要求：
1、要重建的数据类别：
（1）课题计划
（2）课题名单，尤其是真正参加了课题的报名者的履历的确认。
（3）课题报告，包括结题报告和课题分担者的个人报告。
（4）其他文章
2、重建数据的目标和要求：
（1）课题计划、课题名单、结题报告，这三项数据必须重建，由开题人负责。
（2）课题分担者的个人报告，如果个人留有备份，建议重发一遍，若无原稿，可自行决定是否重写。
（3）课题分担者只要曾经发布过报告并被核准，不论是否重发报告，其发布过报告的事实均应得到系统承认，这一数据由开题人确认。
4、数据重建任务清单：
（表内打勾表示要补的数据）
| 课题日期 | 开题人 | 补写计划 | 补写结题报告 | 补名单 | 确认写报告成员 |
| 2009-11-14 | 小撮 | √ | √ | √ （蓝天、晓瑞琪、soso） | |
| 2009-11-14 | 武林阿混 | √ | √ | √（人数很多） | |
| 2009-11-14 | 南瓜叶 | √ | √ | √（糖耳朵） | |
| 2009-11-14 | 当 | √ | √ | ||
| 2009-11-22 | 小撮 | √ | √ | √ | |
| 2009-11-22 | 武林阿混 | √ | √ | √ | |
| 2009-11-21 | 当 | √ | √ | √ | |
| 2009-11-21 | 龙棒 | √ | √ | √ | |
| 2009-11-28 | 小撮 | √ | √ | √ | |
| 2009-11-28 | 龙棒 | √ | √ | √ | |
| 2009-12-5 | 龙棒 | √ | √ | √ | |
| 2009-12-5 | patch | √ | √ | √ | |
| 2009-12-6 | 小撮 | √ | √ | √ |
四、操作指南
1、开题人重新发布课题计划、重写结题报告，方法与以前相同。
2、补名单的操作方法：
第一种办法：课题计划发布之后，点击查看名单，点击名单标题左上角“增补”按钮，打开增补名单页面。在菜单中选定课题组成员，点击确定，添加一个人。然后反复操作，直到所有成员添加完毕。
第二种办法：在发布结题报告时，点击报名名单下部的“补报名”按钮，打开增补名单页面，后面的操作同上。
如果误选了名单，需要向社长报告，由社长来删除误增的名单。
3、确认成员写过报告的操作方法：
注意，这个工作要在结题报告发布之后进行。
打开课题计划，点击标题下方的成员人数，打开成员名单，点击相应名字后面的“是否写报告”一栏的“没写”按钮，将按钮变成“写了”，即确认此人写过报告，系统将不会再催促此人写报告。如果点错了，再点一下“写了”将按钮变成“没写”，就取消了刚才的确认。
