Những điều cần cân nhắc cho Raspberry Pi vận hành dài hạn

 (dzombak.com)
1 điểm bởi GN⁺ 2024-02-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • Để giữ Raspberry Pi hoạt động trong trạng thái không cần can thiệp từ vài tuần đến vài năm, cần thiết kế trước các đường phục hồi tự động khi sự cố xảy ra
  • Hướng dẫn này là một phần của loạt bài về độ tin cậy rộng hơn, thay thế bài viết cũ về giảm hao mòn thẻ SD, đồng thời gộp các cách ứng phó theo từng loại sự cố và mẹo giám sát
  • Các rủi ro chính gồm mất kết nối WiFi, dịch vụ ngừng hoạt động, crash do phần cứng·firmware·driver thiếu ổn định, và thẻ SD bị hao mòn hoặc đầy dung lượng
  • Có thể giảm nhẹ các vấn đề với thẻ SD bằng cách chọn microSD phù hợp, không dùng swap, giảm ghi, dùng hệ thống tệp gốc chỉ đọc, và chạy fsck khi cần
  • Việc tắt journaling có thể giảm hao mòn nhưng lại làm tăng nguy cơ hỏng hệ thống tệp khi crash hoặc mất điện, nên không phù hợp với mục tiêu ổn định dài hạn

Các điểm lỗi cần xem trước khi vận hành dài hạn

  • Để giữ Raspberry Pi online trong thời gian dài, cần xem xét Pi sẽ phục hồi thế nào trong từng tình huống sự cố, đồng thời so sánh cả lợi ích lẫn rủi ro của từng giải pháp
  • Tác giả đang dùng Raspberry Pi trong nhà cho các mục đích như bộ phát FM công suất thấp và bộ theo dõi năng lượng UPS
  • Loạt Raspberry Pi Reliability tổng hợp các loại sự cố tác giả từng trực tiếp gặp phải cùng cách xử lý, đồng thời cũng bao gồm các mẹo giám sát chủ yếu dùng Uptime Kuma
  • Loạt bài này hướng tới một hướng dẫn toàn diện hơn so với bài viết cũ về giảm hao mòn thẻ SD, và các bài được liên kết đóng vai trò là bản thay thế đã cập nhật

Cách ứng phó theo từng loại vấn đề và những lựa chọn nên tránh

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-02-18
Ý kiến trên Hacker News

  • Thay vào đó tôi bắt đầu mua Lenovo mini PC; kích thước 18cm x 18cm x 3cm nên vẫn rất nhỏ gọn
    Dạo này có thể mua được với giá rất rẻ, lại có vỏ và tản nhiệt đàng hoàng: https://psref.lenovo.com/syspool/Sys/PDF/ThinkCentre/ThinkCe...
    Tôi đang đặt một chiếc ngay bên cạnh để dùng, cấu hình i5-8500T, 32GB RAM, 2 SSD; với powertop tự động tinh chỉnh, công suất nhàn rỗi hiện là 5W: https://wiki.archlinux.org/title/powertop

    • Không có GPIO, I2C, SPI. Nếu chỉ tìm một máy chủ nhỏ gọn và nhẹ thì phù hợp, nhưng Raspberry Pi còn phổ biến nhờ khả năng vào/ra vốn hiếm thấy trên thiết bị tiêu dùng/văn phòng
      Có thể thêm kết nối serial tới vi điều khiển, nhưng làm vậy thì giải pháp sẽ kém gọn gàng hơn
    • Năm ngoái tôi đã chuyển Kodi media player từ RasPi 4 sang N3350 mini PC, và không hối hận
      Gần đây tôi cũng đã chuyển NAS (N5105) và máy chạy dịch vụ (3215U) sang mini PC cũ và Chromebook đã mở khóa mua trên eBay hoặc chợ đồ cũ. Rẻ, mức tiêu thụ điện vẫn thấp, còn hiệu năng tính toán thì ở một đẳng cấp hoàn toàn khác so với Pi
    • Tôi cũng dùng theo cách tương tự nhưng dùng Dell 7060
      Ở Úc có hàng nghìn máy được thanh lý khi hết hạn thuê. Chip 8500T hoặc 8700T rất tốt, chính thức chạy được Windows 11 và có sẵn transcoding phần cứng nên rất hợp làm Plex server
      Một chiếc của tôi đã nâng cấp lên 2 SSD 2TB và 64GB RAM, chạy 24/7 không vấn đề gì
    • Tôi cũng vậy. Mua Dell refurbished xong thì đỡ phiền hơn nhiều
      Thẻ SD có lẽ là nguyên nhân gây vấn đề lớn nhất, và nếu tính cả chi phí gắn thêm SSD hay thứ tương tự cho RPi thì nó không còn hiệu quả về chi phí nữa
    • So với phần cứng ARM, điểm hay nữa là có thể chạy gần như bất kỳ bản phân phối Linux nào

  • Lời khuyên đầu tiên không nên là bật chế độ journaling của hệ thống tệp
    Lời khuyên đầu tiên nên là mount hệ thống tệp ở chế độ chỉ đọc, mount /var vào bộ nhớ, và gửi toàn bộ log sang một node có UPS đúng nghĩa và đang chạy NUT, thay vì ghi trên RPi. Nếu hệ thống tệp là chỉ đọc hoặc vùng tạm, thì mất điện về cơ bản là vô hại
    Với một chiếc RPi thì có thể hơi quá, nhưng tác giả nói đang dùng nhiều chiếc ở khắp nhà
    Ngoài ra, có phân vùng hệ thống A/B rồi nâng cấp bằng cách ghi lại toàn bộ phân vùng, sau đó đổi phân vùng active cũng là cách hay. Như vậy, ngay cả khi phiên bản mới có lỗi nghiêm trọng, luôn còn một phân vùng hệ thống hoạt động bình thường và việc khôi phục sẽ dễ dàng
    Tôi đã dùng tốt cách này với nhiều PC cỡ nhỏ/máy tính bo mạch đơn cho các vai trò khác nhau trong hơn 20 năm

    • Tác giả đã đặt liên kết tới lời khuyên về cấu hình chỉ đọc ở vài dòng bên dưới
      https://www.dzombak.com/blog/2021/11/Reducing-SD-Card-Wear-o...
    • Không chỉ /var, mà cả những nơi như /tmp cũng nên dùng tmpfs. Như vậy tuổi thọ thẻ SD sẽ tăng đáng kể
    • Nếu dùng phân vùng hệ thống A/B và nâng cấp bằng cách ghi lại toàn bộ phân vùng, tôi tò mò quy trình nâng cấp sẽ như thế nào
      Không biết tạo image đĩa mới ra sao, rồi đăng nhập vào từng thiết bị để nâng cấp hay có cơ chế tự động hóa nào không
    • Nếu mount hệ thống tệp ở chế độ chỉ đọc thì cập nhật hệ thống hoặc cài phần mềm mới sẽ làm thế nào?
    • Nếu dùng thứ như Docker, khi mount /var vào bộ nhớ thì có thể vượt quá bộ nhớ của thiết bị
      Có thể cần chuyển /var/lib/docker sang bộ lưu trữ phụ

  • Năm 2011 tôi từng làm một sản phẩm thương mại chạy trên một trong những plug computer đời đầu của Global Scale Technologies
    Chỉ bán được 20 chiếc, nhưng tất cả đều bị trả lại do vấn đề hỏng thẻ SD, và chúng tôi phải gấp rút chuyển root filesystem sang chỉ đọc. Từ đó tôi đâm ra thích cách này
    Sản phẩm thương mại đời đầu đó là sản phẩm an ninh gia đình có một ít chức năng home automation, được phát hành mã nguồn mở dưới tên mới vào năm 2021 và hiện chạy trên các máy tính bo mạch đơn dòng Jetson: https://github.com/hcfman/sbts-install
    Giờ đây còn bao gồm cả các mô hình YOLO cao cấp làm trigger. Vì được định hướng là sản phẩm độc lập nên nó hỗ trợ HTTPS, và cũng có GUI bao bọc toàn bộ phần xử lý chứng chỉ. Tính năng này vẫn còn trong phiên bản mã nguồn mở, giúp dễ dùng chứng chỉ tự ký cho các lệnh gọi REST giữa thiết bị
    Ngoài ra, chúng tôi duy trì và mở rộng cách dùng overlayFS bộ nhớ đa phân vùng, đồng thời trong quá trình cài đặt cho cài hệ thống sbts-base trước để người khác có thể dùng nó làm hệ thống nền tảng của riêng họ

    • Tôi cũng có trải nghiệm tương tự. Khi cải tạo một PC Pentium 2 giá 5 USD thành workstation không quạt và im lặng, tôi đã thay HDD bằng thẻ CF
      Sau một thời gian, mỗi lần ghi đĩa hệ thống bắt đầu bị khựng 1–2 giây, khá là khổ sở

  • Với những ai định làm việc kiểu này, trước hết tôi muốn khuyên nên xem liệu có thể xử lý việc cần làm bằng một bo mạch nhỏ như ESP32 hay không
    Mức tiêu thụ điện thấp hơn nhiều, giá chỉ vài đô la, và đủ cho rất nhiều mục đích. Nếu thích phía Python, nhiều bo mạch hỗ trợ cả MicroPython lẫn CircuitPython
    Vì có thể giảm chi phí mua ban đầu và tiền điện phát sinh liên tục, nên đáng để xem xét

    • Tôi cũng hiểu phản biện lo ngại về chi phí thời gian và độ phức tạp của lập trình nhúng, nhưng với người dùng chơi sở thích thì tôi nghĩ đây vẫn là một gợi ý rất đáng cân nhắc
      Những dự án tôi làm bằng vi điều khiển đã ổn định hơn các dự án dựa trên Pi ở mức hàng chục năm, và cũng ít phải lo quên đổi cấu hình SSH mặc định rồi trở thành một phần của botnet. Hình như mặc định từng là pi:raspberry thì phải
      Ngoài MicroPython, hỗ trợ no_std Rust cho ESP32C3 cũng đang tốt lên từng tháng. Với người làm các dự án tự động hóa nhà nhỏ cho vui, các ràng buộc bổ sung đôi khi lại khiến mọi thứ thú vị và đáng làm hơn
      Tuy vậy, với người đã quen Linux thì Pi nhìn chung dễ hơn nhiều, và theo kinh nghiệm của tôi chi phí đắt hơn ít nhất khoảng 10 lần. Cũng cần đưa vào quyết định các cấu hình bổ sung để đạt cùng mức ổn định như khởi động từ SSD, khởi động qua mạng, hệ thống tệp gốc chỉ đọc, thiết lập watchdog, cùng mức tiêu thụ điện cao hơn, đặc biệt là điện năng của Pi 5
    • Có chạy được máy chủ media trên ESP32 không? Không
      Có chạy được máy chủ quản lý mật khẩu trên ESP32 không? Không. Pi-hole? Không được. Bộ điều khiển Unifi? Không được
      Những gợi ý kiểu này dường như tưởng tượng rằng người ta dùng Pi cho những thứ như bộ điều khiển cửa gara, nhưng cứ phản xạ đề xuất ESP32 như một thứ thay thế Pi thì không hữu ích lắm
    • ESP32 và các bo mạch liên quan khá tuyệt, nhưng đòi hỏi một lối tư duy hoàn toàn khác
      Khi có gì đó không chạy, bạn không thể cắm HDMI và bàn phím vào rồi debug tại chỗ trong một môi trường Linux mainline có đầy đủ các tiện ích thông thường
    • Pi Zero tốn tiền điện khoảng 1 đô la mỗi năm
    • Gần đây, trong một cấu hình phức tạp hơn một chút, tôi dùng một Pi Zero cùng nhiều ESP8266/32 giao tiếp với nhau qua HTTP và Wi-Fi
      Đây là lần đầu tôi dùng MicroPython thay vì Arduino, và tôi thực sự thích; đáng ngạc nhiên là nó rất ổn định. Trước đây, các dự án thường hỏng về lâu dài do trạng thái nguồn của Wi-Fi, nhưng cho tới giờ với cấu trúc MicroPython thì chưa gặp vấn đề

  • Việc “cuối cùng phần lớn sẽ là một script định kỳ kiểm tra kết nối Wi-Fi có ổn không, nếu không thì khởi động lại giao diện Wi-Fi hoặc toàn bộ Pi” không phải là hack mà là best practice
    Cũng như các máy chủ quan trọng trong trung tâm dữ liệu cần có kết nối ngoài băng như IPMI hoặc ổ cắm RPDU có thể điều khiển từ xa, các máy chủ quan trọng ở vị trí xa khó tiếp cận cần có script watchdog
    Tất nhiên cần điều chỉnh theo mục đích sử dụng, có xét đến ảnh hưởng của việc reboot và thời gian ngừng hoạt động trước khi reboot; và tối thiểu có thể ghi lại các sự kiện bất thường để điều tra về sau
    Khi triển khai RPi từ xa, việc đầu tiên tôi làm là một script watchdog Bash đơn giản. Nó không chỉ dành cho vấn đề Wi-Fi, mà cho hàng chục tình huống có thể hỏng và có thể được sửa bằng reboot

    • Trên hầu hết các bản phân phối hiện nay, vai trò watchdog kiểu này do init/PID 1, tức systemd, đảm nhiệm
      Nếu không thể tin init quản lý dịch vụ, thì tôi tự hỏi đảm bảo nào cho việc hệ thống cung cấp dịch vụ đến từ đâu
      Có thể tự dựng lại bằng script, nhưng chúng ta đã vượt qua giai đoạn đó rồi. Tôi nhắc systemd nhiều, nhưng không phải để thiên vị; cũng có các lựa chọn thay thế
      Phần lớn dịch vụ không tận dụng đúng môi trường mà chúng tồn tại trong đó. Dường như người ta kỳ vọng các tùy biến theo từng site, chẳng hạn khai báo rằng web server cần một mount cụ thể
      Một chỉ thị hay bị bỏ sót là PartOf=. Nó cho phép gắn việc khởi động lại một dịch vụ hoặc tài nguyên với một thứ khác
      Đơn giản hơn nữa, có lẽ NetworkManager có cung cấp cách tùy biến kiểm tra Wi-Fi/portal. Có thể không cần phải đi theo hướng quá cực đoan
    • Tương tự, tôi dùng ESP8266 để giám sát router Wi-Fi và modem cáp. Khi có vấn đề thì reboot
      Với router, nó thử kết nối tới SSID phù hợp rồi ping router; nếu một trong hai thất bại thì chuyển sang router khác. Tôi đặt hai router giống nhau với cùng cấu hình, nguồn điện được nối vào các tiếp điểm NO/NC của rơ-le SPDT, nên nếu một cái lỗi thì chỉ cần đổi trạng thái rơ-le để chuyển sang cái còn lại
      Nếu router còn sống, watchdog sẽ tải trang trạng thái của modem cáp, rồi ping bất kỳ một trong ba IP nằm trong mạng ISP, có vẻ là CMTS hoặc thiết bị gần đó, để xác nhận hạ tầng HFC còn hoạt động. Lý do là nếu sự cố không thể giải quyết bằng reboot thì tôi không muốn reboot vô ích
      Đáng tiếc là tôi không tìm được cách đặt hai modem cáp có cùng MAC rồi chuyển đổi giữa chúng, và ISP cũng không cho phép hai modem trên cùng một tài khoản, nên nếu modem cáp lỗi thì chỉ còn cách reboot và hy vọng nó chạy tốt
      Tôi còn gắn thêm một rack pin có thể chạy router và modem hơn 30 giờ ngay cả khi mất điện; từ khi làm vào tháng 5/2020, nó gần như luôn online. Code thì kinh khủng, nhưng thực tế hoạt động rất vững
    • Hoàn toàn đồng ý. Watchdog timer là thứ thiết yếu cho vi điều khiển và máy tính chạy phần mềm “mãi mãi”
      Có những việc xảy ra mà ngay cả code và thiết kế hoàn hảo cũng không ngăn được, và watchdog timer sẽ cắt vòng lặp vô hạn rồi reset. Có cả chuyện tàu vũ trụ bị lật bit hoặc sụt áp tức thời; với Raspberry Pi thì còn phải lo hỏng thẻ SD
      Theo tôi biết, Raspberry Pi có watchdog timer phần cứng tích hợp. Arduino thì chắc chắn có
    • Vừa là best practice, đồng thời cũng là hack. Đáng ra không cần phải có, nhưng vì bug tồn tại nên nó trở nên cần thiết

  • Chúng tôi đã vận hành hàng nghìn chiếc Pi trong môi trường production gần 10 năm, và giờ bắt đầu chuyển sang x86
    Hiệu năng/giá của Pi không còn như trước nữa. Gần đây tôi đã trình bày trải nghiệm này tại State of Open Con: https://youtu.be/vX-qK9mxKZI

    • Với tư cách là một đồng nghiệp CEO trong mảng digital signage dùng Raspberry Pi, tôi ngạc nhiên vì bài trình bày không nhắc đến hỗ trợ secure boot có từ Pi 4
      Dịch vụ của chúng tôi chưa dùng, nhưng theo tài liệu thì trông khá chắc chắn và có thể bảo vệ dữ liệu trên disk/SD
      Chúng tôi vẫn khá hài lòng với Pi, và việc chuyển sang các API mở hơn như Mesa/DRM/KMS/FFmpeg giờ mới đạt mức dùng được cũng trông rất hứa hẹn
      Use case chính vẫn là digital signage nên hiệu năng xử lý thô không quá quan trọng. Phần tốn kém là giải mã video thì tất nhiên đã được tăng tốc, và khả năng tương thích ngược trên Pi rất tuyệt. Vẫn có khách hàng tiếp tục chạy Pi1B+ gần 10 năm nay và dùng bản OS mới nhất mà chúng tôi cung cấp
    • Cần xét đến cách sử dụng. Nếu phần lớn thời gian là idle thì tôi nghĩ ARM tốt hơn x86
      Cũng phải nhìn vào tuổi thọ, và ở điểm đó ARM có vẻ cũng sẽ bền hơn x86. Về tính mô-đun thì ARM cũng tốt hơn x86, vì triển khai nhiều thiết bị nhỏ sẽ rẻ hơn
      Nhưng về khả năng mở rộng, tức tính khả thi kinh doanh trong nền kinh tế hiện tại, x86 tốt hơn ARM
      Ngoài ra, mọi biểu đồ nên được tính theo watt. Từ 2 lên 4 mà hiệu năng tốt hơn thì không có gì mới; điều quan trọng là hiệu năng trên mỗi watt có tốt hơn không
      Nhìn theo cách đó, có thể thấy Raspberry Pi 5 không cải thiện hiệu năng trên mỗi watt nhiều như kỳ vọng. Có vẻ như trong lịch sử loài người chúng ta đã vĩnh viễn chạm đỉnh
      Cuối cùng, ở thời điểm hiện tại, hy vọng duy nhất cho một bước tiến nào đó không nằm ở hiệu năng mà ở tính mở là JH7110, nhưng hỗ trợ 3D vẫn còn tụt hậu
    • Tôi tò mò là chúng được dùng để điều khiển màn hình, hay cho thiết bị vận hành dùng GPIO như máy móc lắp ráp sản xuất
    • Tôi tò mò “chuyển sang x86” cụ thể nghĩa là gì

  • Dù không làm bất kỳ điều nào trong số đó, một vài chiếc Pi của tôi vẫn chạy ổn suốt nhiều năm cho đến khi được thay bằng model mới
    Gateway HomeKit/Zigbee và data logger hiện là Pi 4. Rốt cuộc có vẻ thẻ SD tốt và nguồn điện ổn định mới là mấu chốt

    • Đồng ý. Tôi cũng đã chạy nhiều Pi, và khi hỏng thì là do thẻ SD lỗi
      Tôi nghĩ pibenchmark là nguồn thông tin tốt: https://pibenchmarks.com/
      Trước khi mua nhất định nên so sánh thẻ SD
    • Tôi nghĩ cỡ mẫu ảnh hưởng đến trải nghiệm nhiều hơn
      Khi vận hành đủ nhiều thiết bị, mọi thứ có thể hỏng đều sẽ hỏng, và còn xuất hiện cả những kiểu lỗi mới mà bạn chưa từng mơ tới
    • Raspbian OS cũ khoảng trước và quanh năm 2016 có bật ghi access time, nên mỗi lần đọc file đều phát sinh ghi
      Có lẽ đó là lý do sau đó có nhiều báo cáo thẻ bị hỏng
    • Tôi cũng tương tự. Tôi chạy vài chiếc Pi3 làm server Cups nhiều năm nay, uptime chỉ bị reset khi mất điện. Mà mất điện cũng rất hiếm
      Ngoài việc cài Raspbian lên thẻ micro SD, cấu hình Cups, và nối USB với máy in thì tôi không làm gì khác. Một chiếc khác quản lý máy in mạng. Sau đó cứ để vậy
    • Rất thất thường. Có cái gặp vấn đề liên miên, có cái thì ổn rất lâu. Tôi không thấy mẫu hình rõ ràng nào
      Giờ phần lớn đã đổi sang SSD. Không thì cảm giác quá hên xui

  • Tôi ngạc nhiên vì chuyện thẻ SD không được nói đầu tiên, và còn ngạc nhiên hơn vì bài viết không đề xuất boot qua USB
    Tôi để một chiếc Pi bật gần như 24/7 trong nhiều năm, và nghĩ lý do không gặp vấn đề là 1) cấu hình Alpine để gần như không đụng đến disk, 2) không có thẻ SD nào để bị hỏng. Tôi không biết vì sao USB ổn định hơn, nhưng theo kinh nghiệm thì đúng là vậy

    • Cấu hình Argon Raspberry của tôi gắn SSD cũng ổn định
      Lý do duy nhất khiến nó ngừng chạy là khi mất điện. Có lẽ một cục pin chỉ cần chịu được 10 phút là hoàn toàn đủ
    • Tôi muốn biết cách cấu hình Alpine để gần như không đụng đến disk
      Chẳng hạn có phải ý bạn là kiểu như https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode không
    • Tôi từng có nhiều thẻ Pi chạy bằng SD không vấn đề gì. Nhưng đúng một cái thì thẻ SD đột nhiên nóng khủng khiếp, và đó là một chiếc Pi mới đang cấu hình
      Tôi tháo thẻ ra, rồi chuyển thẻ đó và chiếc Pi tiếp theo sang dùng USB SSD. Hơi đáng sợ. Dù vậy như đã nói, tôi cũng có Pi chạy server Cups bằng micro SD nhiều năm không vấn đề gì
    • Hoàn toàn đồng ý. Mọi lần RPi của tôi hỏng đều là do thẻ SD
      Hai chiếc RPi của tôi đều boot và chạy từ USB, và đã chạy tốt nhiều năm
    • Tôi cũng vậy. Tôi boot từ SSD qua M.2 HAT, chạy rất ổn

  • Từ năm 2017, tôi gần như chạy liên tục hai chiếc Pi bằng cùng một thẻ SD. Mất điện khoảng 2–3 lần
    Một chiếc là máy chủ DNS/in, một chiếc chạy Kodi và media nằm trên NFS bên ngoài. Việc duy nhất tôi làm là tắt toàn bộ log, và chưa từng gặp vấn đề gì
    Cả hai đều dùng thẻ SanDisk 2GB. Tôi mơ hồ nhớ là mình từng nghĩ khá ngây thơ kiểu “dung lượng ít → mật độ bit thấp → độ tin cậy tốt”

    • Tôi đã dùng log2ram (github/azlux/log2ram) và hài lòng với kết quả
      Nó mount RAM disk vào /var, và chỉ thỉnh thoảng mới sao chép log từ RAM disk sang thẻ SD. Nhờ vậy vẫn xem được toàn bộ log mà không ghi quá nhiều lên thẻ SD
    • Tôi vẫn chạy Kodi trên Pi 1 bằng nguyên thẻ SD ban đầu, gần 10 năm rồi
      Hầu như lúc nào cũng bật, nhưng thỉnh thoảng tôi vô tình tắt bộ cấp nguồn USB đang nối với nó. Đó là một bộ nguồn nhỏ 5 cổng, cũng gần bằng tuổi nó, và trong cấu hình của tôi nút nguồn quá dễ bị bấm nhầm
    • Tôi có một chiếc RPi chạy không nghỉ từ năm 2014 bằng cùng một thẻ SD, dùng để phục vụ một website thời tiết
      Về cơ bản, tôi mount toàn bộ log và trang web lên tmpfs, còn DB nằm trên thẻ SD và được ghi mỗi 5 phút
    • Tôi vẫn còn chiếc Pi đầu tiên. Có lẽ là Pi 1B
      Nó đã trải qua nhiều lần cài đặt, nhưng hiện là máy chủ DNS dự phòng. Nhìn vào filesystem thì thấy nó đã được dùng làm Pi-hole từ năm 2018, và ngoại trừ vài lần reboot cùng lúc chuyển nhà, về cơ bản chạy 24/7
      Tôi không ghi gì lên SD, mọi thứ đều đưa vào RAM ở /dev/shm. Nếu Pi-hole hiếm khi bị tắt thì chỉ cần tải lại danh sách, mà dù sao nó cũng tải hằng ngày
    • Tôi cũng vậy. Tôi có hai chiếc Raspberry Pi 3, chạy Pi-hole để chặn quảng cáo từ năm 2019
      Về sau tôi bắt đầu dùng chúng cả làm DNS cục bộ và node Tailscale. Có lúc vài tháng không reboot, thời gian chạy liên tục lâu nhất khoảng 11 tháng. Rất bền bỉ. Cắm vào UPS chắc chắn có ích

  • Có người nói “giữ Raspberry Pi online không cần can thiệp trong vài tuần, vài tháng, vài năm phần nào là một nghệ thuật”, còn tôi thì boot kernel NetBSD có filesystem tích hợp sẵn
    Ví dụ dùng kernel INSTALL hoặc kernel tùy chỉnh. Ngay sau khi boot, có thể rút thẻ SD ra, và tùy chọn chroot vào bộ lưu trữ được kết nối
    Làm vậy thì nó chạy được vài tuần, vài tháng, vài năm. Tôi chưa gặp những vấn đề mà tác giả blog nêu ra
    Vấn đề duy nhất tôi phát hiện là ở phía đầu nối nguồn khi dùng vỏ case. Ví dụ, nếu dùng cáp thay thế thì kết nối có thể không chắc. Có thể trên các Pi mới hơn đã cải thiện
    Nhưng cũng có thể nói hầu hết máy tính đều tương tự. Cáp và đầu nối thường là những linh kiện yếu và rẻ. Nếu nguồn bị ngắt do xê dịch, Pi sẽ tự động reboot