【为何设定出错？为何资料没备份？】2.5万件学习历程资料遗失追追追

9月1日开学，居家线上教学2个月后，中小学终于返校上课，尤其高三生更急着想要回去学校，要赶在9月底前， 制作完自己的学习历程档案，将原本7月底就要完成，后来因疫情线上学习未完成的档案，在截止期限上传， 因为攸关明年升学。

但是，没人想得到，就在上传截止前一周，维运工程师一个设定上的操作不慎，竟然造成2.5万件学习历程档案的资料遗失，影响近8千名学生。消息一出，震惊各界。许多师生、家长更是错愕。

这次的资料遗失事件，不只是108新课纲上路以来最严重的资料遗失事故，甚至可以说是，-机关史上少见的大规模资料遗失重大事故，造成存放于-机房的高中生学习历程的资料遗失。

学习历程档案上路是翻转教育的重要关键

学习历程档案之所以重要，不单是因为它可以记录每位学生在高中三年的学习成果和表现，反映出个人在学的学习轨迹，更重要的是，在学习思考与制作档案、成果的过程中，让学生有更多思考、反省和探索机会。要改变传统解题导向、考试机器人训练般的教学型态，让学生更有思考力，学习历程档案是个关键。

大学考招明年甄选申请入学，将正式参采学习历程档案，作为备审资料的重要来源，主要包括两种类型的资料，学习成果、多元表现资料，全程透过数字化作业完成，不少高三生明年申请入学制作备审资料都靠它。

从升学模式来看，学习历程档案的正式上路，让学生除了考试之外，有多一种升学管道做选择，不再只是一试定终生。尤其，对于一些不擅长考试，但有其他才能的学生，更成了可以申请更多学校的关键。

正因为它是高中升学模式的一次重要转变，再加上是这个模式第一次实施，得面对诸多外界更高度的期待和审视。

就在这种新模式展开之际，却遇到突如其来的意外。

学习历程档案的资料遗失事件，9月25日凌晨先在媒体曝光，迅速引起众人的关注。到了早上，不只多家媒体、电视台相继披露，脸书、PTT版上更是出现许多讨论，成了当天民众最关注的重要社会议题。

事件曝光没几小时，教育部国教署就公开证实，发生学生资料遗失的情形，但强调，只有部分，而非全部资料。

因事故遗失的这批资料，不少都是高三生所有，明年马上就要进行第一次用学习历程档案申请入学的作业。流程上，学生得先将学习历程档案，上传到各高中所属学习历程学校系统上，再由学校整批提交到教育部建置的学习历程中央数据库。明年各大学甄试时，会直接从中央数据库取得审查资料。事故就是发生在前半段，学生上传到校内系统的阶段。

从系统架构来看，学生档案上传主要透过到两套系统，学校端使用的学习历程学校系统，以及教育部的学习历程中央数据库系统。学习历程学校系统中还有个模组，可用来记录和追踪每位学生学习历程档案。这次出问题的就是这个学习历程模组。

两阶段向上集中作业

有一批高中的学习历程学校系统，使用了教育部国教署委托暨南大学团队开发的公版模组系统。这套系统原本分散部署在各校，不过，这几年，-为了强化教育体系资安，所以逐步将校内系统搬迁到资安管控更严谨的机房中集中管理。整个搬迁计划，也是由开发公版模组的暨大团队负责。

有395所高中使用公版模组，去年，整批先搬到了台北机房做集中管理，今年因机房升级更换，所以再度从台北旧机房，搬到台中新机房，同样由原团队接手处理。在分工上，新机房分为搬迁和维运各自一组，网站维护、维运机房和虚拟主机管理各有不同负责人。

原定在7月底学生完成资料上传后，在暑假进行系统搬迁工作，但5月突然因疫情停止到校上课，教育部将学习历程上传期限，从7月底延长到9月30日，再加上台中新机房进度，也比原订时程延宕，直到8月底才启用，只能将搬机计划延后到9月进行，导致延期后的学生上传作业与系统移机作业时程重复。

9月5日，暂停学生上传作业后，一组约20人组成的搬迁团队，开始将各校所属学习历程学校系统的公版模组，逐步搬到新机房内的虚拟主机VM上。花了2天左右，完成移机作业后，才陆续开放各校学习历程档案上传作业。新上传的档案，改为直接储存到新机房的公版模组VM硬盘上，不再使用台北机房内的旧系统。

顺利运作十多天后，这些主机因系统更新而重新开机后，维运团队才惊觉异常，其中有3台VM硬盘因人为设定错误，导致部分资料无法连结，造成部分学生资料遗失。

因人为VM设定失误，2万多件学习历程数位档案消失不见！

9月26日，就在事件曝光隔日上午，教育部在记者会公布了资料遗失灾情，初步盘点后，有81所高中学校，在9月5日至9月22日这段期间所上传的学习历程档案，且备份在事故3台VM硬盘的资料，才会受到影响。记者会上，专案计划团队负责人洪政欣强调，此次的资料遗失，是单次性的操作失误，无关系统设计、程式设计，出错的是虚拟主机的设定。

受影响学生多达7,854名，资料遗失合计2万5,210件，这些资料，有些已经教师认证，也有正在等待验证的课程学习成果，或有无需验证的多元表现资料。以类别来看，多元表现的资料，就占了1万5,417件，课程学习成果的资料也有多达9,793件。

记者会上，教育部表示，将协助学生做档案恢复和重传，但对于这些遗失的资料，如何从备份找回，或进行资料救援，当时没有多作说明。事件经过一周后，在截稿前，教育部也没有透露更多进展。

VM设定出错关键环节首度曝光

虽然，教育部目前没有揭露更多细节，从记者会上资讯，这起事故，肇因于人为操作失误，因为VM硬盘设定失误，导致系统更新重开后，部分档案无法连结，才造成资料遗失。究竟如何发生？成了IT圈热烈讨论、分析的话题，甚至有资料救援业者尝试模拟VM出错情况来推测可能情况。

到底是什么样的VM设定失误，竟然造成资料遗失？这是很多人的第一个疑问。根据iThome记者深入追查，这次VM设定失误的关键原因是，在新机房搬移过程中，一名工程师重新建立各校公版模组使用的虚拟主机VM时，不小心误用了错误的VM设定样板才酿灾。

一般来说，VM建置时有一个快速建立作法，可以透过样板（ template）套用既有VM设定，而不用逐一手动设定。这是VMware虚拟主机管理软件内建的样板套用功能，但是，一位工程师建置虚拟主机时，在设定选单中，原本应该要套用“正式环境样板”的VM设定，却有3台VM误选了“测试环境样板”的设定。

这种“测试环境样板”在硬盘设定模式，采取“独立非持续性”的设定，内建还原机制，只要重开机后就自动还原硬盘，等于会清除所有资料。这就是这次VM设定失误的原因。

“独立非持续性”硬盘设定模式，是VMware软件所支援的功能，一般来说，这个设定模式，用在像大型虚拟机升级更新的测试，或类似学校电脑教室这一类应用场景，这些场景都有一个共通之处，原本就需要透过还原的动作，来清空硬盘中的资料。所以硬盘里就算有资料，也不是太重要的资料，但这一次，误设的3台VM硬盘里存放的资料，是学生辛辛苦苦准备的课程学习成果或备审资料，攸关其能否升学。

9月22日，因资安要求进行例行性系统更新后，系统重开机，同一位工程师才发现自己套用了错误的样板，但因为VM已经完成还原作业，硬盘上的旧有档案无法连结，造成部分资料遗失。因为一台公版模组VM，可供20～30校使用。395校一共部署10～20多台VM，其中出事的3个VM，支援81校所用。

备份机制未完善下，冒然开放学习历程档案上传作业

令各界更想不透的是，为何资料救不回来，难道之前都完全没有备份机制吗？经过我们的追查，其实原本的确有备份机制，沿用已久。在旧机房，暨大维运团队的确有一套备份计划，每天进行本地备份和异地备份。

高中9月1日开学，学生马上就要展开学习历程档案上传作业，为明年考招新制做准备，暨大维运团队为了赶上线，9月5日展开搬迁，赶着几天内要搬完并上线，让各校学生使用。

在9月4日，搬迁到台中新机房前一天，维运团队除了原有本地和异地备份之外，对学习历程档案公版模组的资料再进行一次完整备份作业。这是为何后来只有9月5日到9月22日期间遗失资料，但9月5日前的资料都还在的缘故。

但问题就出在，新机房启用太匆促，直到8月底才正式营运，学习历程公版模组系统赶9月初进驻时，机房备份机制的设定还没完备，不只没有留存搬迁期间可用来还原的备份版本和快照，也还没完成台北和台中异地备援架构，让资料互为备援。

在不能延宕后续升学资料审查作业的时程压力下，维运团队为了要赶着上线恢复服务运作，所以，在备份机制没完善的情况下，就开放了学习历程档案上传作业。系统上线后，学生开始传档案，这些资料陆续送到新机房做储存，但机房备份机制还是处于未启动的状态，等于从学校重新开放学生上传档案那一天起，这些学生上传资料都没有额外的备份。直到9月22日，因资安要求进行例行性系统更新，系统重开机后，发现部分资料已经遗失。

虚拟化平台原本就可以内建提供VM快照的备份机制，但是，工程师所误选的样板因为采取了“独立非持续性”的设定，这个模式，因为预设还原硬盘来清空资料，因此就不需要启动快照功能。甚至，在一台VM内若有多颗虚拟硬盘，其中一颗若设定成独立非持续性，当用VMware软件建立VM的快照时，就会绕过这颗硬盘，只对其他硬盘做快照，换句话说，就会没有可以用来回复这颗硬盘的快照版本。VMware也证实，的确在这种情况下，设定了独立非持续性的硬盘模式后，VM硬盘就不会被快照。

也就是说，从9月7日前后开放学生上传，到工程师发现VM异常的这段时间，长达两周，这段期间并没有留存可用来还原的备份版本或是快照档案，再加上还没完成台北和台中两地机房的异地备援架构，让资料互为备援，台北旧机房内的系统就无法同步更新取得新上传的资料，一直到9月22日为止，才造成了这段期间的资料遗失后，无法从备份或快照恢复，之后也很难复原，甚至救不回来。

学习历程资料遗失详细事件表

 2020年 
各校的学习历程档案公版模组系统向上集中，第一阶段先搬到台北hicloud机房。每天进行本地机房备份和异地备份。

 2021年6月22日 
因疫情学生停止到校，教育部将学习历程上传期限，从7月底延长到9月30日，导致学生上传作业与系统移机作业时程重复。

 2021年8月底 
台中hicloud新机房完成，但比原订时程晚。

 2021年9月4日 
向上集中第2阶段准备将学习历程档案公版模组系统从台北hicloud机房，搬迁到台中hicloud新机房。除了原有每天本地和异地备分外，对公版模组的资料再进行一次完整备份作业。

 2021年9月5日 
暂停学生上传作业，开始进行移机作业。分工上，暨南大学团队新机房分为搬迁和维运各自一组， 网站维护、维运机房和虚拟主机管理各有不同负责人。

 误用错误VM设定样版 
移机作业展开后几天，设定工程师有次在新机房执行新VM建置作业时，套用了错误的VM设定样板（误选了“测试环境设定”样板）。（下图为模拟图，非真实画面，图片来源／OSSLab）

 关键设定差异 
“测试环境VM设定”与“正式环境VM设定”最大差异是，测试环境所用的硬盘设定模式，采取“独立非持续性”的设定，内建还原机制，只要重开机后就自动还原硬盘，等于会清除所有资料。

 2021年9月7日左右 
完成移机作业，开放学习历程档案上传作业，档案上传后，改为直接储存在新机房的公版模组VM硬盘上。不再使用台北机房内的旧系统。（各校上线时间仍会视情况调整，主要集中在9月7日这几天）

 2021年9月22日   事故日 
 VM还原事故 
因资安要求进行例行性系统更新，系统重开机后，同一位设定工程师发现样板套用错误，但因为VM已经完成还原作业，硬盘无法连结，造成特定期间内储存在出事3台VM硬盘上的学生资料遗失。

 资料遗失盘点 
9/5到9/22期间上传且存放在误设的3台虚拟主机的学生资料

 备份问题调查 
因机房启用太匆促，备份机制的设定还没完备，所以，没有留存搬迁期间可用来还原的备份版本和快照，也还没完成台北和台中异地备援架构，让资料互为备援。最后一版完整资料是9/4在搬迁作业前进行的完整VM备份版本。

 2021年9月24日 
 紧急通知各校 
委外维运团队以电子邮件，逐一通知受影响学校，通知学生登入平台确认上传档案是否正常。

 2021年9月25日3:00 
学习历程档案遗失事件在媒体曝光，引起各界议论。

 2021年9月25日 
 第一次公告 
国教署说明学习历程档案资料遗失事件及受影响范围，说明后续补救作业，81校一共7,854名学生，合计2万5,210件资料遗失。

（上图为学习历程档案的课程学习成果资料上传的操作示意图）图片来源／采威国际资讯

 2021年9月26日10:30 
教育部召开记者会说明2.5万笔学习历程档案遗失采行因应机制及精进作为，同日也发第二次公告

 未来备份策略 
加强虚拟储存异地备份、定期检视备份作业及还原演练，另外针对档案严格要求落实异地备份，而且每天本地备份的次数最少6次，VM快照增加到每日6次，以保留完整资料和备份。对于负责维运的厂商每天落实备份情形，也要建立相关监督机制，甚至一些重要系统要调整、操作时，需要有专家全程在场监督或提供建议。

 2021年10月1日 
 第三次公告 
国教署说明事件处理最新进度，包括待处理案件学生人数，以及资料件数。（截至10月1日，仍有3千多人，约6,050件的资料待处理。）

资料来源：iThome整理，2021年10月5日