Mailman 3 November 2024 - Bit-dev

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

Difference between mountLockAquire() and mountProcessLockAcquire()
by c.buhtz＠posteo.jp Nov. 23, 2024

Nov. 23, 2024

Hello, can someone explain to me the difference between the two methods mountLockAquire() and mountProcessLockAcquire() in class MountControl in common/mount.py? I don't get it. I was refactoring common/mount.py::MountControl.checkLocks() and also added some unit tests (PR #1942 [3]). Regards, Christian [1] -- <https://github.com/bit-team/backintime/blob/dev/common/mount.py#L823> [2] -- <https://github.com/bit-team/backintime/blob/dev/common/mount.py#L780> [3] -- <https://github.com/bit-team/backintime/pull/1942>

1 0

Backintime "fix" for slow backups
by Stephen Carr Nov. 23, 2024

Nov. 23, 2024

Dear Bit-Team I have been using BIT for years then in the last month backups took 3 hours and not the usual 20 to 30 minutes. I installed 1.5.3 with no change in the speed - then I remembered that I had tweaked the configuration. Luckily you store the conf file with the backup data so it did a diff of an older (fast) conf and a slow conf. What I had done was enabled nice with rsync (there is a warning) in Expert Options. Backups ate back to the usual 20-30 minutes. Any chance of reporting the clock time taken for a backup and store in in the info file? Thanks Stephen carr

2 2

Is BiT suitable for archive backups of Timeshift snapshots?
by zahlman Nov. 20, 2024

Nov. 20, 2024

Currently, I have a separate partition for `/home`, and I allow Timeshift to store snapshots there. I have external media, but they're rarely connected - so they wouldn't be suitable targets for Timeshift's normal operation. I had the thought that from time to time it would be a good idea to back up my Timeshift snapshots explicitly on another physical drive. Naively, I tried running BiT as root (since the `timeshift` folder is owned by root), and setting up a profile to back up `/home/timeshift`, with no exclusions (reasoning that everything in there is there for a reason and might be needed if it were used for a system restore). I pretty promptly ran into the issue described in https://github.com/bit-team/backintime/issues/1003, which surprised me because if the log file is in `/root/.local` then it should be underneath `/home/timeshift`. But I guess that the snapshot contains symlinks to things in the running system and rsync tries to follow those. More worryingly, *the drive was still active* after I received the error message in the terminal (and the GUI stopped updating, and a "failed" marker file appeared in the backup folder). It was still active for several seconds after I quit BiT. (Fortunately this was on a new drive with tons of room, so no risk of exhausting the disk.) I also found https://github.com/bit-team/backintime/issues/1583 which makes it sound like maybe this isn't supposed to be possible, if people are arguing to exclude "snapshots" by default.... Is backing up `/timeshift` folders a supported use case? Are specific file-pattern exclusions necessary; and wouldn't they cause a problem with restoring from the backup (or rsyncing back to the original snapshot folder)? Would it have actually worked despite the one error message, such that I should have just let it run (it seems like rsyncing literally millions of files, most of them being hard links, would have been rather slow)? Are symlinks a problem, and if so how would I work around it? Karl Knechtel {:>

2 2

Release 1.5.3
by c.buhtz＠posteo.jp Nov. 13, 2024

Nov. 13, 2024

Hello, Please allow me to announce the new and fresh release of Back In Time. The minimum supported Python version has been raised to 3.9. The user manual has migrated to a new format and build system, now including sections on user callbacks and detailed example scripts. The code base has undergone extensive refactoring. FCron support has been added. The English strings in the GUI have been optimized. Serbian language is now available in both Latin and Cyrillic scripts. Interlingua (Occidental) has been introduced as a new language. The libnotify-bin (notify-send) dependency has been removed, as Back In Time now uses DBus for notifications. See the release info and changelog for more details: <https://github.com/bit-team/backintime/releases/tag/v1.5.3> <https://github.com/bit-team/backintime/blob/dev/CHANGES> Best, Christian Buhtz and the Back In Time team.

1 0

Article about Back In Time on Linux Weekly New (LWN)
by c.buhtz＠posteo.jp Nov. 11, 2024

Nov. 11, 2024

Hello, I got in contact with an author from LWN and was interviewed about the project. As the result now we do have a fresh article about it: <https://lwn.net/SubscriberLink/996720/d992c6a549e414f4/> Regards, Christian

3 2

This weekend: Release 1.5.3
by c.buhtz＠posteo.jp Nov. 8, 2024

Nov. 8, 2024

Hello, If no one else knows a reasons against it I will release 1.5.3 this weekend 3 weeks after its release candidate. After it I will have a closer look at a pending PR implementing gocryptfs support as a replacement for EncFS. <https://github.com/bit-team/backintime/pull/1897> The plan is to release version 1.6.0 with gocryptfs support as soon as possible. Regards, Christian

1 0

Wording: "Snapshot" or "Backup"?
by c.buhtz＠posteo.jp Nov. 6, 2024

Nov. 6, 2024

Hello folks, I am interested in your opinions about this. Looking into my foggy memory it seems that I somehow asked this question before. But I couldn't find out when and where. So my apologize if this is a duplicate. In my experience around BIT I would say that the term "Backup" is more appropriate for what we currently call "Snapshot". So I would like to change that. - For someone not knowing BIT (e.g. potential new users and translators) the term "Backup" is clearer. - Snapshot might be understood by some people as an image of the file system. - When writing about BIT (in Issues, Forums, etc) most of the time I do use the term "backup" out of the stomach without thinking about it. I do understand that "Snapshot" is kind of fancy and points to the timeline feature. But I would prefer to use the technical correct term "Backup" instead of a marketing term. What do you think? Regards, Christian

4 3

Release Candidate for Back In Time 1.5.3
by c.buhtz＠posteo.jp Nov. 1, 2024

Nov. 1, 2024

Hello, I am happy to announce a new Release Candidate in preparation for the Back In Time release version 1.5.3. Please report back if you use it, even if no issues are found. <https://github.com/bit-team/backintime/releases/tag/v1.5.3-rc1> Changes: - Extensive code refactoring. - Added support for FCron. - Improved text labels in the graphical interface. - User manual updated. - Serbian language now available in both Latin and Cyrillic scripts. - New language: Interlingua (Occidental). - Minimum supported Python version raised to 3.9. - Removed dependency on libnotify-bin; now using DBus for notifications. We encourage everyone to test this Release Candidate, as it helps ensure a higher-quality final release. Without testing and feedback, creating an RC would be pointless. Your input is essential to improving the project! Thank you very much for support! Christian Buhtz

3 2