Mailman 3 - Bit-dev - python.org

Release Candidate 1.5.4-rc1 targeted for Debian 13 "Trixie"
by c.buhtz＠posteo.jp Feb. 13, 2025

Feb. 13, 2025

Hello, I am happy to announce a new Release Candidate in preparation for the Back In Time release version 1.5.4 which is targeted for the upcoming Debian release version 13 (Trixie) this summer. Please report back if you use it, even if no issues are found. <https://github.com/bit-team/backintime/releases/tag/v1.5.4-rc1> This version is set to be released with Debian 13 (Trixie) this early summer and will remain available for the long lifetime of that Debian version. EncFS, used for encrypted profiles, has been marked as deprecated and is schedule for removal in 2026. The Smart & Auto remove GUI has been reorganized and renamed into "Remove & Retention", with improvements to the user manual section. Its behavior remains unchange. An offset minute can now be configured for hourly schedule options. Some config file fields have been moved to a newly introduced state file. License and copyright information is now provided in machine-readable SPDX format, following the REUSE standard. # Contributors This version received extensive support from contributors (in alphabetical order): - @bremnere - David Gibbs @fallingrock - graysky @graysky2 - Samuel More @mooresamuel - Iván Rodríguez @ivanrdgz03 - Peter Sevens @sevens - David Wales @daviewales - Dylan Wilson @dylan-wilson-usq - Also not to be forgotten are the many people who supported the project by testing it, providing feedback, reporting issues, and analyzing problems. # Known major issues open - qt_probing.py may hang with high CPU usage when running Back In Time as root via cron (https://github.com/bit-team/backintime/issues/1592) - File permissions handling and therefore possible non-differential backups (https://github.com/bit-team/backintime/issues/988 & https://github.com/bit-team/backintime/issues/994) # Changelog * Changed: More clear and intense warning about EncFS deprecation and removal (https://github.com/bit-team/backintime/issues/1904) * Changed: Updated desktop entry files * Changed: Move several values from config file into new introduce state file ($XDG_STATE_HOME/backintime.json) * Changed: Completed license information to conform the REUSE.software and SPDX standards. * Breaking Change: Auto-remove rules "Free inodes" and "Free space" disabled by default (https://github.com/bit-team/backintime/issues/1976) * Fix!: Smart-remove rule "Keep one snapshots per week or the last week" use calendar weeks * Fix: The width of the fourth column in files view is now saved * Fix: Snapshot compare copy symlink as symlink (https://github.com/bit-team/backintime/issues/1902) (Peter Sevens @sevens) * Fix: Crash when comparing a snapshot with a symlink pointing to a nonexistent target (Peter Sevens @sevens) * Fix: Crash (KeyError) opening language setup dialog with unknown locale/language * Feature: Open user manual (local if available otherwise online) via Help menu * Feature: Toolbar context menu to display the buttons in different combinations with icons and text (https://github.com/bit-team/backintime/issues/1105, https://github.com/bit-team/backintime/pull/2002) (Samuel Moore @s4moore) * Feature: Add offset minutes to hourly schedules (David Gibbs @fallingrock) * Doc: Remove & Retention (formally known as Auto-/Smart-Remove) with improved GUI and user manual section (https://github.com/bit-team/backintime/pull/2000) Regards, Christian Buhtz on behalf of the maintenance team

1 0

du command slow over multiple snapshots
by William Seligman Feb. 5, 2025

Feb. 5, 2025

I'll start by acknowledging that is not a bug in backintime. If this is the wrong place to ask this question, please consider leaving a suggestion to where I should ask. I've set up a Linux server to serve as a repository for remote backintime backups for several systems. I'm trying to create a report, for each system's backup, of the amount of disk space used for the latest snapshot (easy, I'll show the command below), and total disk space used for all the snapshots for that system. To the disk space used for the latest snapshot (or any particular snapshot), there's no difficulty. For example: /usr/bin/du -sx /pool/backup/backintime/mysystem.example.com/user/1/last_snapshot/backup/* The problem comes when I want to see the total disk use for `mysystem.example.com`. This command gives the correct answer, as far as I can tell: /usr/bin/du -sx /pool/backup/backintime/mysystem.example.com/ The problem is that while the answer appears to be correct, as the number of snapshots increases, the du command takes longer and longer to execute. For some of the backups with a large number of files, it takes hours for that one du command to execute. My guess is that this has something to do with how du is handling the hard links in order to get that correct answer. Based on my fiddling around, it appears that du is visiting every snapshot directory and going through all of files it finds, even if there are only a few files that differ between snapshots. The result appears to be that if that first `du` command takes ten minutes due to the number of files in the snapshot, the second `du` command takes ten minutes * the number of snapshots. Is my guess correct? Or is this due to something else? Is there any work-around? The purpose of this report I'm creating is to understand how much actual disk space is being used over time for backintime backups. If I found that new snapshots were taking up a lot of space, it would mean the system's user was refreshing a lot of large files in-between snapshots. I'd want to re-evaluate the frequency of their backups or how long backintime retained the snapshots. AlmaLinux 9.5 backintime 1.3.2 I obtained backtime via the EPEL repository: dnf install backintime-qt Disk has: # df -h /pool Filesystem Size Used Avail Use% Mounted on /dev/mapper/POOL-pool 17T 5.1T 11T 33% /pool # df -hi /pool Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/POOL-pool 262M 58M 205M 22% /pool -- -- Bill

3 3

Remove & Retention: Improved GUI and added user manual section
by c.buhtz＠posteo.jp Feb. 1, 2025

Feb. 1, 2025

Hi, As discussed earlier I improved the GUI about the Auto-/Smart-Remove feature, now known as Remove & Retention. I also added a section to the user manual. The goal was only to investigate, document and clarify how that feature currently work. To minimize the risk of bugs, the behavior should be kept as it is in this initial step. Despite this step sounds minimal it was much more work than I though in the beginning. The modifications are not merged yet but available via my PR. Feedback is welcome. <https://github.com/bit-team/backintime/pull/2000> The relevant docu section can be found here in its markdown format: <https://github.com/buhtz/backintime/blob/fix/1976retention/doc/manual/src/r…> Looking forward to your feedback. Regards, Christian

1 0

configuration to execute a plain copy - not a full backup
by FPA Jan. 25, 2025

Jan. 25, 2025

Hello, I'm wondering is it possible configure BiT in a way so that it executes just a plain copy, not a full backup of a file when the file in [Source} is newer then in Destination]? I'm trying to figure that out but didn't find a solution for that. Any help is much appreciated. TIA Back-in-Time v1.4.1-1 - Linus Mintv21.1

2 1

Auto-remove: Request opinions about new GUI and behavior
by c.buhtz＠posteo.jp Dec. 27, 2024

Dec. 27, 2024

Hello Folks, I investigated the current auto-/smart-remove behavior and documented it. I found inconsistent behavior and minor bugs. There is a lot potential to improve and refactoring. Before starting with this I would like to request your opinions and suggestions about the next steps. I prepared a Mockup of the new auto-remove dialog-tab. It should explain all details. It also should be easier to understand for the users. If not please let me know. The overall goal is to make the behavior consistent and easier to understand without the need to read a user manual. So please have a look at this issue for details: <https://github.com/bit-team/backintime/issues/1945#issuecomment-2550610014> I would prefer ongoing discussion in the issue. But of course feel free to use another channel, too. Thank you and regards, Christian

2 6

Distinctive application logo for Back In Time
by c.buhtz＠posteo.jp Dec. 18, 2024

Dec. 18, 2024

Hello, it is a known and long standing topic that Back In Time need its own logo. Beside technical details also license and copyright issues need to be taken into account. The later was often a problem in the past. I created a new (meta) issue outlining all relevant details, including technical and legal aspects to consider. I would appreciate it if someone would review them. I maybe have forgotten something to consider. The goal of this issue is to use it in the designer community (e.g. Inkscape) to ask for contributions. https://github.com/bit-team/backintime/issues/1961 Regards, Christian

1 0

New Mastodon account @backintime@fosstodon.org
by c.buhtz＠posteo.jp Dec. 6, 2024

Dec. 6, 2024

Hello, Back In Time now has a Mastodon account @backintime@fosstodon.org [1] that will be used additionally to this mailing list as an announcement channel. Because I was not able to get a free (and working) email account for the project I used my own email to register this Mastodon account. Regards, Christian [1] -- <https://fosstodon.org/@backintime>

2 1

Should BIT warn about "system files" in the backup?
by c.buhtz＠posteo.jp Dec. 5, 2024

Dec. 5, 2024

Hello, this is related to a user reporting problems with BIT. But backups his hole system. <https://www.reddit.com/r/debian/comments/1h6x9ci/debian_12_apt_glibc_238_no…> I often encounter problem reports by users backup system files and restoring them back. We do know that BIT and any other backup solution is not intended to do things like this. An image software is better suited for use cases like this. I wonder if BIT might warn users if they try to add files/directories outside from $HOME to there include list? Or simply when starting BIT in root mode the first time there could be a one-time-warning mentioning that BIT is not intended for full system backups and an image software should be used instead. What do you think? Regards, Christian

2 1

Force Bash and/or Sh shell on remote host?
by c.buhtz＠posteo.jp Nov. 27, 2024

Nov. 27, 2024

Hello, I need your opinion and expertise in this case. I like to know if my approach to solve the problem is a good idea or not. We have two issues about the problem that the shell (fish & hetzner) on the user's remote server does not support our (bash/sh compatible) commands. <https://github.com/bit-team/backintime/issues/1905> <https://github.com/bit-team/backintime/issues/1745> Beside this issues I also discussed several approaches to a solution in the German Debian forum. <https://debianforum.de/forum/viewtopic.php?t=190714> First of all it is not possible to support "exotic" or all kinds of shells. My solution would be to force the bash and/or sh shell on the remote host using a command structure like this ssh user@server bash -c "foobar" If "bash" is not on the server there will be a clear error message we can redirect to the users. And when setting up a new SSH backup profile several checks are done on the remote server. Checking the availability of bash/sh shell could be one of that checks. Converting our inline shell commands to POSIX conform ones is not a solution. Not all shells in the wild are POSIX conform. To my knowledge most of the inline shell scripts used by BIT are bash conform. Not sure if sh would do it, too. Because of that I would prefer to force bash only in the beginning until we tested everything with sh, too. Regards, Christian

2 3

Your gut feeling about auto remove?
by c.buhtz＠posteo.jp Nov. 27, 2024

Nov. 27, 2024

Hello, Please take this as a user survey and answer out of your gut ignoring technical details or wording and translation issues. Looking onto the "Auto-remove" tab you do see this option. "Keep one snapshot per week for the last N weeks" Does this take the current week into account even if it is not yet complete (e.g. today it is Thursday)? Regards, Christian

5 7