Mailman 3 March 2026 - Bit-dev

Scheduling broken in 1.6.1 ?
by c.buhtz＠posteo.jp March 23, 2026

March 23, 2026

Hello, if you are using Back In time 1.6.1 please check if your scheduled profiles are running as expected. Maybe 1.6.0 users, too. Let me know if this is not the case. Best would be to open an issue for the report. Regards, Christian

1 0

Much earlier removal of EncFS support than planned
by c.buhtz＠posteo.jp March 20, 2026

March 20, 2026

Hello, EncFS support in Back In Time will be removed much earlier than previously planned [1]. Monitor the progress in this PR #2449 [2]. Recent development work on the implementation of gocryptfs support revealed that maintaining EncFS in parallel introduce significant complexity and maintenance overhead. Continuing to keep EncFS in the code base would block progress on gocryptfs and jeopardize the entire plan. I have decided to remove the complete mounting logic and re-implement it from scratch. Refactoring the existing EncFS logic would consume disproportionate time and effort for a component that is scheduled for removal. As a consequence, EncFS must be removed before gocryptfs can be fully implemented. The original plan was to add full gocryptfs support and release that verison of Back In Time with the upcoming Debian 14 (~end of 2027), removing EncFS afterwards. This is no longer feasable. The version of Back In Time version for Debian 14 will include full gocryptfs support will not longer support EncFS. Users currently relying on EncFS should start planning a migration to gocryptfs. Migration documentation and guidance will be provided. Additionally, there is the plan to ensure that the latest EncFS-supporting version of Back In Time remain usable on Debian 14, when installed from upstream. Please let me add that the security issues with EncFS are known since the year 2014 [3]. Removing it from Back In Time was decided in 2023, and first deprecation warning within Back In Time was released in July 2024 with version 1.5.0 [4]. Best regards, Christian Buhtz Current maintainer & lead developer [1] https://github.com/bit-team/backintime/issues/1734 [2] https://github.com/bit-team/backintime/pull/2449 [3] https://sourceforge.net/p/encfs/mailman/message/31849549/ [4] https://github.com/bit-team/backintime/releases/tag/v1.5.0

1 0

Backing up another machine form this machine and storing the backup on this machine
by Jeff Silverman March 11, 2026

March 11, 2026

Hello, I have been using backintime for more years than I can remember and I love it. It just works. I was wandering through the documentation and I realized that I could use backintime to backup my local web server. Currently, the web server has no backups, if something happens to it, I just rebuild it and copy the content to the server. But it occurred to me that I can use backintime to backup the server. My problem is that when I backup my server, it stays on the server. There are five solutions that present themselves: 1) Use an NFS mount from my enormous disk drive that I currently use as the backup destination 2) Use a CIFS (samba) mount from my enormous disk drive that I currently use as the backup destination 3) Use a cron job or similar to run rsync over SSH to pull the files from the server to the enormous disk drive. This seems like the safest solution from a computing security point of view because if the server gets compromised, the putative bad guy does not get write access to the enormous disk drive. 4) Use a cron job or similar to run rsync on the server to push the files from the to the enormous disk drive. 5) Ask if there is a better solution. The problems with solutions 1, 2, and 4 is that if a bad guy gets into my server, then he or she has write access to my enormous disk drive. Yes, I am aware that if a bad guy compromises my server, then he or she can write malware and the backup system will copy it to the enormous disk drive. But unless I do something stupid, that's as far as the malware can get. I see that version 1.6 is in the release process - my question might be answered by upgrading. Is that the case? Thank you Jeff Silverman https://jeffsilverman.ddns.net jeffsilverm(a)gmail.com -- Jeff Silverman jeffsilverm(a)gmail.com http://jeffsilverm.ddns.net <https://jeffsilverm.ddns.net>.

1 0

Update on BackInTime 1.6 Release for Ubuntu LTS
by c.buhtz＠posteo.jp March 2, 2026

March 2, 2026

Hello everyone, Version 1.6 is an important release as it introduces several deprecations and functional changes, and it informs and prepares users about that. In my view, it is important and urgunt that Ubuntu LTS users receive this update so they aren’t caught off guard in later LTS release if BIT stops working within their setup. From my experience, Ubuntu LTS users tend to stay on their LTS version for the full five-year-support period. Version 1.6.0 was unfortunately released rather close (11 days) to Ubuntu's "Debian Import Freeze" (February 19). Two days later, version 1.6.1 followed with fixes, leaving only 9 days before the Import Freeze Deadline. Packaging in Debian was also delayed, which meant we missed the Ubuntu deadline. Fortunately, Fabio Fantoni stepped in again to handle the Debian packaging. Our last chance now is a so-called “freeze exception”: <https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/2142983> I’m not fully familiar with the decision process at Canonical, but the Ubuntu maintainer responsible is the same as for Debian. I’m unsure whether that is an advantage or disadvantage. Just wanted to keep you all updated. Fingers crossed! Best regards, Christian

1 0