SaaS系统的数据到底放在哪？助贷机构该问清的五个问题

库 33 MB，74 张表；库里最大的表是线索表，3888 kB，客户表只有 464 kB。录音文件不在库里的 —— 1400 通通话记录里 678 条挂了对象存储的键，其余 722 条是空的；服务器本地那个上传目录，25 MB，只剩 3 个文件。备份目录 3.4 GB，而文件历史备份只有 116 KB。

这五组数字，把「数据到底放在哪」这个问题拆成了五个不同的落点：库、文件、备份、日志、配置。多数人问这句话时，脑子里只有一个答案——「在服务商的服务器上」。但真正会出事的地方，从来不是「在谁那儿」，而是「存了几份、缺了哪一份、删的时候删的是哪一份」。

这篇按五个问题走：库在哪、文件在哪、备份覆盖了谁、隔离到什么粒度、留存与删除怎么算。每个问题配一条在现场可验证的检查动作——不用听对方讲架构，直接让他打开后台或者给你看一份导出。文中的数字来自自有平台库内实测与服务器实测（含测试租户），只说明数据形态，不代表任何机构的经营规模。

一、SaaS系统的数据到底放在哪：先分清五个落点

「数据在云上」这句话没有信息量，因为一套 SaaS 系统里的数据至少分成五个落点，每个落点的存放方式、备份方式、删除方式都不一样。

库——客户档案、线索、跟进记录、订单、权限。这类数据有结构、有关系，几乎都在关系型数据库里。它是唯一一份「改一行就影响业务」的数据。

文件——通话录音、合同扫描件、客户上传的身份证和流水。这类东西体积大、不参与查询，通常不放库里，库中只存一个键（key），实体在对象存储上。这一步的分离，是绝大多数「导出不全」问题的根源。

备份——库的定期快照、文件的历史版本、对象存储自身的多副本。三者是完全不同的机制，覆盖范围也不同，但常被一句「我们有备份」打包带过。

日志——操作记录、登录记录、访问记录。它的价值和客户数据不一样：客户数据丢了是业务损失，日志丢了是举证能力损失。

配置——字典、角色、审批流、话术模板。它不是「数据」但比数据难重建，因为它装的是经验。

分清这五个落点之后，「数据放在哪」才变成一个能回答的问题。下面四节，逐个落到具体数字上。

如果你还停在「SaaS 到底是什么形态」这一步，建议先读助贷SaaS系统是什么，把责任划分和交付方式弄清；这篇只往下钻一层，钻进存储。

二、库在哪：74 张表 33 MB，客户数据只占 464 kB

先把体积摆出来。整套库 33 MB，74 张表合计占 23 MB（其余是索引之外的开销和空页）。体积最大的五张表依次是：线索表 3888 kB、访问日志 2432 kB、操作日志 2432 kB、文章表 1896 kB、角色菜单表 1072 kB。客户表 656 行，占 464 kB。

这组数字传达三个信息，都挺反直觉。

第一，业务数据比想象的小得多。656 个客户的档案只有 464 kB——不到半兆。真正的 SaaS 客户如果有一万个客户，也就是几兆的量级。所以「我们数据量大所以要私有化」这个理由，在客户档案这一层基本不成立；真正撑体积的是日志、录音和附件。

第二，日志比业务数据占地方。访问日志 5089 行、操作日志 7262 行，各占 2432 kB，加起来是客户表的十倍。日志是越积越多的东西，而且几乎没人清理。它不会拖慢业务查询（业务查询很少扫日志），但它会实打实吃掉备份空间和时间。

第三，文章这类内容数据混在同一个库里。文章表 65 行、正文合计 653 kB，占 1896 kB（含索引）。这说明平台级内容和租户级业务在同一套库、同一个连接池里——不是错，但它决定了一件重要的事：做租户级数据隔离时，这类表是「不需要隔离」的例外，下一节会讲到它的风险。

库在哪这件事，现场能验的动作只有一个：要求看一次「库的物理位置」和「连接方式」。物理位置不是问他「在阿里云还是腾讯云」，而是问「有没有跨地域容灾、主库在哪个可用区」。连接方式问得更细一点：应用连库是不是走内网、有没有开公网端口。这一条能问出很多事——把数据库端口暴露在公网的团队，通常也没做别的隔离。

顺带说一句：库的体积和部署方式没有必然关系。云上一样是 33 MB，私有化也一样是 33 MB。差别在后头——备份谁做、做几份、放在哪。

三、文件在哪：678 条录音在对象存储，本地只剩 3 个文件

库里 1400 条通话记录，678 条挂了对象存储的键（678 条全部非空，没有半截脏数据），另外 722 条没录音。而服务器本地那个上传目录只有 25 MB、3 个文件。

这组数字说明存储已经分层了：文件实体在对象存储，库里只留键，本地几乎不留东西。这是个正常、也是更可靠的结构——对象存储自带多副本，比单机磁盘安全。但它带来四个必须问清的事，每个都可能让「数据拿走」落空。

第一，键和原文件名不对应。对象存储上的键通常是一串路径加随机串（比如按年月分目录加哈希名），原始文件名存在库里或者根本没存。好处是不会重名、不会因为中文名出问题；坏处是你拿到一堆文件，不知道哪个是哪个客户的。所以导出时必须同时给「键与业务的对应表」，否则文件等于一堆无名素材。

第二，下载链接有有效期。对象存储的私有读通常靠签名链接，链接里带过期时间。这意味着「给你一个清单让你自己下」这种做法，隔几个小时就失效。真要交付，得用一次性打包或者批量下载工具，不能给链接了事。

第三，桶在哪、谁有权限。桶的地域决定了数据实际存放在哪个机房；桶的权限决定了有没有「公开读」这种隐患。公开读的桶，只要路径泄露，文件就能被任何人拿走——这类事故在行业里不算少见，且往往不是被攻击，是被搜索引擎抓到。

第四，录音和通话记录是两条链。记录写了、文件没上传，或者文件传了、记录删了，都会出现对不上的情况。这套库里 678 条有键、722 条没键，比例大致对应「接通 649 通、未接通 751 通」——没接通自然没录音，逻辑是对的。但你要问的是：有没有核对机制，能定期把「有记录无文件」和「有文件无记录」都列出来。这套核对没有现成的表，只能靠脚本对。录音这一层的管理细节，可以对着助贷通话录音怎么管理那篇看，那边把存储、调阅、留存分开讲了。

现场能验的动作：随便挑一条有录音的通话，让对方当场打开；再让他把这条录音的键名报给你。如果他能报出键名、并且能在对象存储里定位到同一个文件，说明这条链是通的；如果只能点开听、说不出键名，说明业务层和存储层之间有一层他没讲清。

四、备份覆盖了谁：库备份 3.4 GB，文件备份 116 KB

这是全文最值得盯的一组数字：服务器上的备份目录里，数据库备份合计 3.4 GB（里面还分子目录放着关系库、MySQL、Redis 三类），而文件历史备份只有 116 KB。

116 KB 是什么概念？一张 1240 像素宽的配图大概 150 KB。也就是说，文件这一侧的备份，几乎等于没有。

这不是谁偷懒，而是结构决定的：库可以整库 dump，几十兆几百兆都好处理；文件动辄几十上百 GB，靠「备份目录」复制不现实，正常做法是依赖对象存储自身的多副本和版本控制。问题是——「依赖对象存储」和「有备份」是两件不同的事。对象存储保证的是「硬件坏了数据还在」，它不保证「误删了能恢复」。要防误删，得开版本控制或者开回收站；这两项在多数对象存储里都是可选开关，默认不一定开。

所以「备份」这个词要拆成四问，一问一答地对：

库备份多久一次、保留几份、放在哪台机器上。「放在同一台机器上」是最常见的问题——机器挂了，库和备份一起没。合格的答案是异地或者至少另一个存储。

备份能不能恢复。这一条只有做过恢复演练才算数。没演练过的备份，只能叫「疑似备份」。演练不用复杂，拿一份备份恢复到临时库、跑一次「能不能查到昨天的客户」，十分钟的事。

文件有没有版本控制或回收站。不开的话，删了就是删了。开了之后要问保留多少天。

备份里含不含日志和配置。日志在库里，通常跟着库一起备；配置也在库里，一样。真正的盲区是「对象存储上的文件」和「服务器本地目录里的东西」——后者往往被排除在备份策略之外。这套库的本地目录里只有 3 个文件、25 MB，问题不大；但如果一个系统把附件放在本地磁盘上，那它就是备份策略里最容易被忘掉的一块。

现场能验的动作：让对方把最近一次恢复演练的记录给你看。不是备份日志，是恢复记录——恢复时间、恢复到了哪个时间点、谁验证的。拿不出来，就按「没有可恢复的备份」对待。

五、隔离粒度：62 张表带租户字段，12 张不带

多租户系统里，租户之间靠一个字段隔开。这套库 74 张表里，有 62 张带租户字段，12 张不带。不带的那 12 张是：迁移版本表、文章分类、文章、咨询线索、节假日、回款流水、平台管理员权限、平台管理员、退款、系统配置、租户表本身、访问日志。

这 12 张里，绝大多数是「平台级」的，本来就不该按租户隔离——文章是全站内容，节假日是公共日历，平台管理员是运营方的人。这个结构是对的。但结构对，不等于问不出来东西。它至少暴露了三件需要确认的事。

第一，那 12 张「不带租户字段」的表里，有没有混进租户数据的。最可疑的是访问日志和咨询线索：如果它们是全平台共表、靠别的方式区分来源，那查询时一旦漏了条件，就会跨租户看到别人的访问路径或留资信息。这不一定是漏洞，但一定是需要现场验的地方。

第二，62 张带字段的表，条件是「接口层强制加」还是「靠开发自觉」。这句话是判断隔离质量的唯一分水岭。强制加，意味着有一条统一的入口把租户条件拼进去，漏不掉；靠自觉，意味着每个接口自己写一遍，写漏了就是跨租户泄露。问法很具体：「有没有一个地方统一注入租户条件，在哪个文件」。答得出来、并且能指给你看，才算过关。

第三，租户之间的数据是不是物理同库。是。33 MB 的库里放着 20 个租户的数据，靠字段区分。这不是缺点——物理同库是 SaaS 成本能压下来的原因。但它决定了一件必须提前知道的事：「给我单独一个库」这种要求，在标准 SaaS 里通常做不到，能做到的版本叫独立部署，价格是另一套。这条如果想不通，就会在采购后期变成一场争吵。相关口径可以对照私有化部署和SaaS哪个好那一节的六个维度，尤其是「数据控制权」拆出来的三个问题。

现场能验的动作：要一次「跨租户越权」的测试说明。不是要他演示越权成功，而是问他怎么测的——用 A 租户的账号去请求 B 租户的资源 ID，返回什么。返回「无权限」是正常的，返回「不存在」更严谨（不泄露资源是否存在）。这个问题一问，对方就知道你懂。

六、留存与删除：9 张表能软删，没有一张写到期时间

这套库 74 张表里，有 9 张带软删标记（客户、线索、员工、渠道、产品、消息、提醒计划、客户档案、租户）。而带「到期」语义的字段只有三处：任务表、租户表、提醒计划表——它们记的是业务到期，不是数据留存期。换句话说：这套系统里没有任何一张表定义了「数据留多久」。

这在中后台系统里很常见，但它和现在的合规要求对不上。金规〔2025〕9 号要求合作机构名单公示与更新、核心风控不得外包；《个人贷款业务明示综合融资成本规定》要求明示表逐项列清并在签约前确认；《金融产品网络营销管理办法》要求营销素材「发布前审核、全程留痕、资料存档」。这三份文件对「留痕」的要求都很具体，但对「留多久」给的是原则、不是天数——所以真正的答案在你的内部制度里，而系统必须能支撑这个答案。

要支撑，就得回答三件事：

软删之后数据去哪了。打标记的删除，数据还在表里，查询时过滤掉。好处是可恢复，坏处是「删了」其实没删——客户要求删除个人信息的时候，这种删除是不算数的。这一点必须清楚：软删是业务手段，不是合规手段。

物理删有没有入口、谁有这个权限。多数系统没有，只能由服务商运维在库里操作。那就得问清：提工单多久处理、处理完给不给书面确认、备份里的副本怎么处理（备份里的数据不会因为你删了主库就消失）。

日志留多久。操作日志是举证的核心，也是体积增长最快的一块（这套库里两张日志表各占 2432 kB）。留太短，出事查不到；留太长，成本和风险都在。合理做法是按类型分：登录与权限变更留长，普通查询留短。至于「留多久」的依据，可以对着助贷机构怎么做合规留痕那篇的六类记录看，那里把「谁产生、存哪、留多久、谁能调」四件事逐类列过。

现场能验的动作：让对方演示一次删除。删一条测试客户，然后回答三个问题：库里还在不在、备份里还在不在、页面上还能不能查到。三个答案凑齐，才算把「删除」这件事说清。很多产品只能答第一个。

七、五个问题怎么问，答案怎么验

把前面五节压成五问，每一问配一条「要求对方演示什么」。这张清单的价值在于：它不问你听不懂的架构，只让你看能看见的东西。

问题一，库在哪。要求看：主库的地理位置与容灾方式，以及应用连库走不走内网。答不上来「有没有公网端口」的，直接扣分。

问题二，文件在哪。要求看：随便点开一条录音，报出它的存储键名，并在管理后台里定位到同一个文件。只能播、不能定位，说明这层是黑盒。

问题三，备份覆盖了谁。要求看：最近一次恢复演练的记录，以及文件侧有没有开版本控制。只给备份日志、不给恢复记录的，按没有备份算。

问题四，隔离到什么粒度。要求看：租户条件在哪里统一注入，以及一次越权测试的返回结果。答「每个接口自己加」的，风险自评。

问题五，留存与删除怎么算。要求看：删一条测试数据后，库、备份、页面三处分别是什么状态。只答「我们会删干净」的，等于没答。

五问里如果有一问答不上来，不必立刻放弃这家——多数产品在某一层是薄弱的，这很正常。真正要判断的是：它薄弱的那一层，是不是你最在意的那一层。一个只有五个人的团队，最在意的通常是「录音别丢」；一个要给资金方交材料的团队，最在意的通常是「日志能不能调出来」。这两件事落在完全不同的落点上，选型结论也完全不同。选型的整体框架可以对着客户管理系统哪个好用那五道筛子走，其中第五道「数据能不能整包带走」和这篇是一件事的两面。

八、数据存放最常被问的四个问题

SaaS系统的数据放在服务商那里，和放在自己服务器上，安全性差多少？不能一概而论，得看三件事各自谁做得更好：谁做备份、谁做权限、谁做升级打补丁。多数中小机构的自建服务器，这三件都做得比专业服务商差——不是能力问题，是没人。所以真正该问的不是「放哪更安全」，而是「放在那儿之后，这三件事谁负责、做到什么程度、我能不能验」。这三问答不清，放哪都不安全。想把三种形态的成本与责任一次看清，可以看助贷CRM私有化部署价格和助贷CRM部署要多少钱两篇，前者讲一次性投入，后者讲服务器与运维。

数据会不会被服务商的人看到？技术上，运维能看到——他有库的权限。所以这个问题只能靠制度回答，不能靠技术回答。要问三件具体的事：运维查库有没有审批和记录、生产数据能不能导出到本地、开发测试用不用真实客户数据。第三件最容易出问题：很多团队图省事，直接把生产库拷到测试环境。这一条问出来，对方答得含糊，就说明有。

能不能只导出我自己的数据？能，但要看导出的是「能看的」还是「能用的」。能看的是一张客户列表，能用的是客户、线索、跟进、通话、订单、回款各一张表加上字段说明和关联关系。前者拿去做备份够了，后者才能换系统。另外别忘了文件：录音和附件如果不跟着一起导，换系统之后历史通话就只剩文字记录。这一点和助贷客户资料怎么防止被导出讲的是同一套字段，只是方向相反——那边防的是内部人带走，这边要的是合法拿走。

我们的客户数据要不要单独加密？要区分两件事：传输加密和存储加密。传输加密（HTTPS）现在是标配，没什么好谈的；存储加密分两种，整库加密（透明加密，运维也看不到明文之外的东西，但能查）和字段级加密（手机号、身份证单独加密，连库管理员也看不到明文）。字段级加密会牺牲查询能力——加密后的手机号没法模糊搜索，只能精确匹配，所以通常要配一个「盲索引」字段来支持查重。要不要上这一层，取决于你的客户数据敏感度和资金方的要求，不是越加密越好。权限这一侧的配套可以对着CRM权限怎么分级看，那边讲的是「谁能看到哪一列」，和加密是两件事，要一起做才有意义。

最后回到那五个数字：库 33 MB、本地文件 25 MB、对象存储 678 条键、备份 3.4 GB、文件备份 116 KB。它们不是「这家做得好不好」的评分，而是一份体检报告的读法——凡是有数字的地方，就能验；凡是只能说「有」的地方，就得当场让他打开看。数据放在哪这件事，问到第五层，剩下的都不是技术问题了。想看这套系统在存储、备份、权限、留痕上分别做到哪一步，可以查看价格与版本说明，对着上面五问一条条核。