江苏泰而坦自动化科技有限公司规模大不大
2026/9/25 5:56:14
监控这个需求，很多人以为贵的不是硬件，而是存储。我朋友开了一家小便利店，买了两台摄像头，问了一圈云存储：一年一百多，30天循环备份更贵，两三个摄像头加起来一年就得小五百；插内存卡呢？64G的卡没几天就满，循环覆盖写个一年半载，卡基本就废了。后来我把家里吃灰的树莓派3B和一台几十块钱的二手摄像头翻出来，用夸克网盘当远程存储，搭了一套 24×7 监控存储与回放系统，从采集、切片、同步到回放，全程没再花一分钱。这篇就把这套玩法的完整思路、关键配置和踩坑过程手把手拆给你看。适合想低成本看店、看家、看仓库的朋友，也适合手里正好有闲置单板机想折腾点实用项目的人。
1. 设计思路：先把“省钱”和“省心”都算清楚
1.1 传统监控方案的钱到底花在哪
很多人买摄像头的时候只看机器价格，觉得一百多块的摄像头已经很便宜了，结果装完才发现，真正的持续支出在“让录像变得可回放”这件事上。
厂商云存储通常是按年付，7天循环和30天循环价格差不少。一台摄像头一年一百多看着不多，但两三个摄像头、三五年下来，就是一笔不小的数字，而且数据锁在厂商的生态里，想换平台就把历史录像全丢了。内存卡更尴尬：60G左右的卡，720p画质大概能循环覆盖三五天，想留一个月得经常换卡；监控的频繁写入还非常伤卡，过热、坏块都是常见事。至于NVR整套方案，设备加硬盘起步就要上千，布线安装也麻烦，一般家庭用户根本用不出它的价值。
我搭这套系统时的核心逻辑是：硬件尽量用闲置的，存储用已经有的网盘空间，外加一点手写脚本。本地只放一个很小的临时缓冲目录，真正长期保存和远程回放都交给夸克网盘。这样不但云存储年费为零，也不必为监控专门买存储卡。
1.2 这套系统的数据流：采集、切片、同步、回放
这条链路其实不复杂，简单说就是四个环节：摄像头出视频流，单板机定时把它们录成小段文件，网盘客户端或同步脚本把本地录像传到云端，最后用夸克网盘App或局域网网页播放回放。
摄像头如果走RTSP协议，输出的是H.264编码的实时流。单板机里的FFmpeg每隔10分钟启动一次，抓取一段600秒的视频，存成一个独立的MP4文件。为什么不用一个超大文件连续录？因为单个文件一旦损坏，后面的视频基本全没救；切成10分钟一段，坏也不过坏10分钟，传输同步也方便，网盘在线播放时定位某一时间点非常快。
这就像快递分拣：一大卡车散装货物运输容易出错，但打包成一个个标准小箱，转运、盘点、找回就轻松多了。后续回放时，文件命名里已经带日期和时间，按名字找片段就行。
1.3 为什么不推荐成品云存、纯本地存储或自建NAS
成品监控的云存储虽然省事，但它是一个封闭的付费订阅服务，续费断供就看不到历史，摄像头换品牌后录像也基本带不走。纯本地存储则要面对两个现实问题：设备要是被偷，录像一起没了；内存卡或USB盘长期连续写入，寿命损耗很快，坏一张卡就等于丢一段时间的录像。
自建NAS能把数据掌握在自己手里，但对多数家庭用户来说门槛偏高。要让外网随时访问家里的NAS，要么做端口映射、内网穿透，要么自己申请公网IP，这些操作都会暴露家庭网络入口，安全风险和维护成本都不低。网盘方案的最大优点就是这些事都不需要你自己做：数据从单板机推上去，远程回放直接走网盘App，相当于把远程访问的运维全部外包了。代价只是上传带宽占用和网盘的容量限制，这两点可以通过控制码率和定期清理来平衡。
2. 硬件准备：把吃灰设备配成监控“壳”
2.1 摄像头怎么选：老RTSP摄像头是首选
我所说的“乞丐版摄像头”不是画质差到没法看，而是指它至少能输出标准视频流，分辨率720p起步。这里强烈建议优先找支持RTSP协议的老网络摄像头，海康、大华、宇视这些牌子的老款，基本都能开RTSP，流格式通常直接是H.264，单板机只需要-c copy就能把视频原样存下来，CPU占用很低。
如果手里只有USB摄像头，也不是不行。二三十块钱的USB摄像头插上就能用，但要注意两点：一是它输出的多半是MJPG或YUV原始流，单板机可能要转码成H.264，对CPU有要求；二是USB线的长度限制了安装位置，摄像头只能放在单板机附近。
拿到老摄像头后，先用VLC或ONVIF工具扫一下它的RTSP地址。不同品牌路径格式不一样，比如海康常见的是：rtsp://admin:密码@摄像头IP:554/Streaming/Channels/101
大华、宇视的路径规则不同，网上按“品牌 + RTSP地址”都能查到，或者直接在摄像头的后台网页里看“媒体设置”页面。总而言之，先把画面拉出来，后面所有事才有得谈。
2.2 单板机怎么选：树莓派、香橙派、闲置小主机都行
单板机的任务其实不重：拉流、写盘、同步上传。如果摄像头输出H.264且你直接copy，单板机基本不需要转码，双核就够跑；如果要用USB摄像头转码，那最好四核起步。
树莓派3B、3B+是我用得最稳的组合，注意用质量好的5V电源，别用手机充电器糊弄。树莓派4B性能更强，但风扇和散热要跟上。香橙派之类国产板子更便宜，就是有些型号的内核和驱动比较折腾，需要确认系统镜像里的摄像头驱动和硬件编码器能否正常使用。家里有吃灰的x86小主机也可以，跑Linux绰绰有余。
供电和散热是决定7×24稳定性的关键。很多人的单板机装完就跑，结果半夜过热降频，摄像头流一断，整个录像就断了。我的做法是：树莓派加一个几块钱的散热片加小风扇，摄像头用独立12V电源，不要和单板机抢电。
2.3 本地存储、带宽和网盘空间的底线准备
本地存储不需要多大，但必须和系统TF卡分开。树莓派的TF卡长期承受录像写入，几个月就可能有坏块，这是很现实的教训。我一般把录像临时目录放在外接的闲置U盘或USB硬盘上，系统卡只负责运行系统。
上传带宽决定了能同时传几路录像。按1Mbps码率计算，一路摄像头一小时产生约450MB数据，一天约10.8GB；2Mbps码率对应约21.6GB/天。家宽上行一般有30Mbps以上，同时传一两路1080p没问题。夸克网盘的免费空间通常也够存一周到一个月，具体能存多少取决于码率和保留天数。
如果网络断了，录像会继续写本地，等网络恢复后再由同步脚本补传上去，所以本地临时目录的容量不能太抠。另外建议在路由器里给摄像头和单板机分配固定IP，不然重启后IP一换，脚本地址就全废了。
3. 核心实现：录像、同步与回放的完整落地
3.1 先让摄像头在单板机上正常出画面
拿到摄像头后，先在单板机上确认设备能被系统看到。RTSP摄像头直接测试取一帧：
ffmpeg -rtsp_transport tcp \ -i "rtsp://admin:密码@192.168.1.64:554/Streaming/Channels/101" \ -frames:v 1 check.jpg如果能看到一张正常画面，就说明地址、用户名、密码、端口四个要素全部正确。RTSP传输这里我建议强制加-rtsp_transport tcp，虽然视频流会经过TCP封装稍大一点，但比UDP稳定太多，否则局域网稍有信号波动就花屏断流。
如果是USB摄像头，先看设备节点：
lsusb v4l2-ctl --list-devices然后用FFmpeg抓一帧确认编码格式：
ffmpeg -f v4l2 -input_format mjpeg \ -video_size 1280x720 -framerate 15 \ -i /dev/video0 -frames:v 1 snap.jpg比较坑的地方是USB摄像头的设备节点不固定，有时候是/dev/video0，有时候重启就变成/dev/video1。我的建议是先固定好摄像头插的USB口，再通过udev规则给它绑定一个固定节点名，省得录制脚本一个月后突然找不到设备。
3.2 FFmpeg每10分钟录一段完整MP4，不依赖segment
这里我先说结论：用定时任务启动FFmpeg，每10分钟录一个独立MP4文件，比让FFmpeg用-f segment持续切片更稳。segment模式对MP4的moov atom处理经常出幺蛾子，而且在网盘同步时会容易把正在写的半截文件上传上去。独立进程的好处是每次录完都是完整文件，同步、回放、校验都省心。
录制脚本我放在/usr/local/bin/record_one.sh：
#!/bin/bash # 每10分钟录制一段600秒的视频，先写临时目录再搬入录像目录 SRC="rtsp://admin:123456@192.168.1.64:554/Streaming/Channels/101" DIR=/mnt/recordings TMP=/mnt/tmp LOCK=/tmp/record_one.lock flock -n "$LOCK" || exit 1 mkdir -p "$DIR" "$TMP" ffmpeg -hide_banner -loglevel error \ -rtsp_transport tcp -i "$SRC" \ -t 600 -c copy -an \ "$TMP/$(date +%Y%m%d_%H%M%S).mp4" mv "$TMP"/*.mp4 "$DIR/" 2>/dev/null这段脚本有几个细节值得说。-c copy表示直接复制视频流，不重新编码，老摄像头是H.264流时这点尤其关键，CPU占用几乎可以忽略。-an是去掉音频，监控场景大多数时候不需要声音，能省不少体积。flock -n是为了防止上次录制还卡着没退出，新一轮定时任务又启动，导致两个FFmpeg抢同一个摄像头。
然后配置cron定时任务：
*/10 * * * * /usr/local/bin/record_one.sh >> /var/log/cam_record.log 2>&1注意cron环境里的PATH很短，脚本里最好把ffmpeg写成绝对路径，或者在脚本开头加一行export PATH=/usr/local/bin:/usr/bin:/bin，否则很容易出现“手动跑正常，定时任务没反应”的情况。
如果手头只有USB摄像头，把-i参数换成v4l2源，并把-c copy改成硬件编码，树莓派用h264_omx，性能强一点的机器用libx264 -preset veryfast -b:v 1500k。原因是USB摄像头输出的MJPG或YUV流不能直接塞进MP4里被播放器顺畅识别，必须先转成H.264。
3.3 把录像自动同步到夸克网盘
同步是这套系统的灵魂。如果你家里有一台常开的Windows或macOS电脑，最简单的办法是装夸克网盘官方客户端，把录像目录通过Samba共享出来，然后在电脑里把这个共享目录作为自动备份目录。树莓派那边只需要装个Samba服务：
sudo apt install samba然后在/etc/samba/smb.conf里加一个共享段，把/mnt/recordings暴露给局域网。电脑端映射网络驱动器后，夸克网盘客户端会自动把新出现的录像文件传到云端。这个方案的优势是完全用官方客户端，稳，不需要额外折腾，缺点是你得有一台常开的电脑。
纯Linux单板机环境下，我用了另一个组合：alist + rclone。alist是一个开源网盘桥接工具，可以把夸克网盘挂载成本地WebDAV服务，然后rclone定时把/mnt/recordings同步上去。具体做法是：
- 在单板机上部署alist，按官方文档完成夸克网盘的登录授权，挂载好网盘存储。
- 开启alist的WebDAV开关，记下WebDAV地址，一般类似
http://127.0.0.1:5244/dav/网盘挂载目录。 - 配置rclone：
rclone config选择webdav类型，url填alist的WebDAV地址，vendor选Other，这样会生成一个叫quark的remote。
- 同步命令：
rclone copy /mnt/recordings quark:监控录像 \ --transfers 2 --size-only \ --log-file=/var/log/rclone.log这里我刻意用copy不用sync。sync会把remote端多余文件删掉，我们只需要增量上传，copy更安全。--size-only可以避免反复上传时间戳不一致的文件。最后再加一条cron：
*/30 * * * * rclone copy /mnt/recordings quark:监控录像 --transfers 2 --size-only >> /var/log/rclone.log 2>&1录像文件到网盘后，本地如果空间紧张，可以等同步确认完成后再删旧文件。稳妥的做法是在rclone命令加&&，同步成功后再执行本地清理：
find /mnt/recordings -name "*.mp4" -mtime +7 -delete这个命令只删7天前的本地文件，网盘端保留更长时间。有一点需要提前声明：alist这类第三方桥接工具属于开源社区方案，使用前请确认符合网盘服务条款，个人备份量级问题不大，但别拿去做超大规模商用转发。
3.4 回放：网盘在线播放和局域网网页播放两手准备
录像都传上去了，回放自然不用再装一堆厂商App。最直接的方式是打开夸克网盘App，进“监控录像”目录，按日期文件夹找到目标时间点，在线播放MP4。网盘中视频播放器对H.264的MP4支持很好，拖动到关键时间点也顺畅。
如果设备在局域网内，我更推荐在单板机上起一个极简网页服务：
python3 -m http.server 8080 --directory /mnt/recordings --bind 0.0.0.0手机浏览器访问http://单板机IP:8080，就能看到按日期命名的目录和MP4文件列表，直接点开就播。这个方案不依赖网盘，也不暴露到外网，纯局域网内回放速度最快。想要带着密码保护再加一层Basic Auth就行，只是日常个人使用没必要搞复杂。
文件命名是回放系统里最容易被忽略的细节。我的录像文件名是20250412_183000.mp4这种格式，日期加时间一目了然。今天出事了，看一眼时间戳，再顺着网盘目录点进去，10分钟内就能找到对应视频。
4. 七天二十四小时跑下来，我遇到的那些坑
4.1 摄像头掉线、黑屏、花屏的排查顺序
这套系统最怕的是摄像头掉线，而掉线原因通常不是摄像头本身，而是供电和网络。摄像头画面突然黑屏，我一般按这个顺序查：先看摄像头指示灯和后台管理页面，确认设备本身还活着；再ping一下摄像头IP，确认网络通；最后看单板机上的录制日志，确认FFmpeg是否有重连报错。
RTSP流用TCP传输后，花屏情况会少很多。如果FFmpeg还是偶发报错，比如出现method SETUP failed，多半是摄像头同时被多个客户端连接，有的老摄像头只允许一个主码流会话。这时候要么停掉VLC测试，要么让录像脚本只拉一路流。还有一次我排查了半天，结果是摄像头固件后台的RTSP开关被重置关了，重新打开就好。
USB摄像头的坑更多集中在设备节点和供电上。节点漂移问题前面提过，供电不足的表现则是画面隔几十秒卡一下，或者设备直接消失。换一根质量好的USB线和独立供电的USB HUB，能解决掉大半症状。
4.2 TF卡频繁损坏：把写入量降下来
树莓派最怕的是24小时不停写TF卡，系统日志、录像文件一起堆进去，半年到一年卡就会出坏块。我的解决办法是三层：
第一，录像目录无论如何要放外接存储，TF卡只放系统。第二，把系统日志调到最小，syslog和journald都限制体积，临时文件尽量用tmpfs，重启就清掉也不会伤卡。第三，关掉swap，树莓派对swap的使用频率很低，但每次换页都在磨损TF卡。
用iotop可以清楚看到是哪个进程在持续写盘。排查下来，除了录像，最常见的就是系统自带的日志转储和包管理器的自动更新。把不必要的计划任务一律停掉，整个系统的安静程度会提升很多。
如果实在没有USB硬盘，只有一张老TF卡，那就接受“卡会坏”的事实，把录像文件不停往网盘传，本地只保留最近一两天。这样即使卡突然坏了，损失也就一两天录像。
4.3 网盘同步失败、漏传：先别急着怀疑网盘
我一开始直接把录像目录设成同步目录，结果发现总有些文件没传上去，后来定位到原因：FFmpeg写文件期间，同步客户端就把还没写完的MP4抓去传了，传了个半成品，后面就跳过了。解决办法就是脚本里“先写临时目录，再mv进录像目录”这个设计。
alist/rclone方案里，漏传更多是登录态过期和脚本并发导致的。夸克网盘在alist里的授权登录态会过期，过期后rclone显示PermissionDenied，日志里能看到401或403。我的做法是写一个小脚本定时检查rclone日志，发现鉴权错误就用curl发个本地通知，提醒我重扫一次alist授权。
还有一点容易踩：rclone上传大文件时如果网络中断，残留的partial文件下次可能卡住。--transfers 1或2控制并发以后，这类问题会少很多。再配合每30分钟一次的定时重试，漏传事件基本能被自然消化。
4.4 长期运行变慢、不稳定的自检清单
7×24系统跑久了，最常见的问题不是一次性的设备故障，而是性能慢慢劣化。我给自己总结过一个自检清单：摸机身温度，看单板机是否降频；查dmesg里有没有USB设备反复断开重连；看网络连接数，有没有进程崩溃后变成僵尸连接占满内存；最后检查系统时间，树莓派如果没有联网校时，录像文件名会越偏越远，回放定位直接乱掉。
树莓派这种设备，如果白天太阳直晒，机箱温度超过70度就会开始降频，FFmpeg录制偶发超时。解决办法是改善散热，同时给录像脚本加一个超时退出：
timeout 650 ffmpeg ...这样哪怕一次录制卡在摄像头无响应，650秒后也会自动杀掉进程，下次定时任务还能正常启动。再加上cron每10分钟兜底，整个系统就有了最基本的自愈能力。
5. 还能怎么玩：从看店到看家再到动作告警
5.1 画质、存储与留档时长怎么平衡
监控录像不是画质越高越好，而是够用就好。720p可以看清人形轮廓和动作，1080p能看清车牌，2K以上在固定机位监控里往往只是浪费空间。码率决定了体积：
| 分辨率 | 常见码率 | 每天容量 | 1TB空间可存 |
|---|---|---|---|
| 720p | 1Mbps | 约10.8GB | 约90天 |
| 1080p | 2Mbps | 约21.6GB | 约45天 |
| 1080p | 4Mbps | 约43.2GB | 约23天 |
如果你主要想看有没有人半夜进店，720p、1Mbps完全够用，还能多留一倍历史。如果追求更多细节，就用1080p但控制码率在2Mbps以内。监控场景画面变化小，H.264压缩效率很高，不需要像影视视频那样追求高码率。
网盘空间有限时，建议设一个“本地留7天，云端留30天”的默认策略。院子里或店门口的关键位置，甚至可以只留动作触发前后的片段，进一步压缩存储。
5.2 多摄像头接入的统一规划
一台单板机带多路摄像头，关键是不要把所有FFmpeg进程挤在一起抢CPU。我的做法是给每个摄像头单独一个录制脚本，脚本里把输出目录分开，比如/mnt/recordings/cam01/、/mnt/recordings/cam02/。定时任务分别执行，cron里错开一两分钟启动，避免同时开始录制导致磁盘IO高峰。
网盘同步时也是一样，rclone按顶层目录慢慢传，--transfers控制在2左右，不要一梭子全传上去把上行带宽占满。多路同时写入时，本地存储尽量用USB硬盘或SSD，U盘扛不住并发写入。
5.3 加一点动作检测，录像和告警更省空间
纯24小时循环录像是最笨的办法，但也是零开发成本的办法。等系统稳定跑起来之后，还可以给单板机装一个开源运动检测软件（比如Motion或Frigate），检测到画面变化时只保存事件前后30秒的视频，很多时间静止的场景就能不录像，存储占用直接砍掉一大半。
告警侧的做法是在运动检测触发后，让脚本发一条HTTP请求到手机推送服务，相当于实现了“有人进入画面就通知你”的功能。这一层我不展开写了，因为方案比较多，而且涉及各家推送平台的配置，更适合作为下一步折腾的方向。先把录像链路跑稳，再谈智能告警，顺序不能反。
最后再分享一个心得：这套系统跑起来后，真正让我觉得值的地方不是省了那几百块云存储费，而是它把几个本来吃灰的东西串成了每天真正在干活的生产力工具。第一次出回放需求时，打开夸克网盘App，直接翻到对应时间点把视频拉出来，那种踏实感挺强的。摄像头对着公共区域时，注意别侵犯邻居隐私，监控范围尽量控制在自己地界内，这是我自己一直守着的基本线。