Separate GUI from backends to support more backup engines

[aryoda]

This feature request was posted by @solisinvictum in #1199:

Edit: If I had a free wish, i would wish BackInTime would ditch rsync/$what_ever_is_used and would use something like Borg or duplicati. Because then the user could choose any backend (wich can be mounted or used with ftp, webdav, what ever) as destination. And could use options like compression, encryption, dedublication or a combination of them.

[aryoda]

@solisinvictum

I would like to understand and document your feature request here.

Could you answer some questions please?

1. Are you asking to use Back in Time ("BiT") as GUI and allow separate backup tools (even non-rsync) as (non-GUI) backup backend?

2. The backup/restore location is IMHO theoretically independent of the used backup backend. Should this be a generic part of the BiT GUI or configured individually in the backup backend (since some backends have their own implementations of mounting, encryption and deduplication support)?

[buhtz]

Hui, what a big wish.
Ignoring the resources needed for something like this I would argument this is conceptual not possible. Borg & Co do work very different from rsync. They have different goals. Their backups do result in data-containers (e.g. ZIP) and not in files and folders in the regular file system. They also do not use hardlinks.

I would say it seems much easier to write a GUI for Borg instead of make BIT independent from its backup engine.

[emtiu]

I must agree with @buhtz: In my personal opinion, it's impossible to separate Back In Time from rsync. The way that rsync uses hardlinks to save space, and the fact that the backed-up files are saved as 1-to-1 copies on a regular filesystem are the main distinguishing characteristics of Back In Time.

Take a look at https://github.com/restic/others to see what I mean: Only very few backup solutions carry the filesystem tag, which means that they store the backed-up files the same way as Back In time.

But because Back In Time operates in such a simple way, there is some flexibility to add additional features: If you want to use BiT, but have encryption, just store your BiT backups on a LUKS-encrypted volume. If you want compression, integrity-checking or (additional) deduplication, just store your BiT backups on a btrfs or ZFS file system.

Just my 2 cents :)

[solisinvictum]

@solisinvictum

I would like to understand and document your feature request here.

Could you answer some questions please?

1. Are you asking to use _Back in Time_ ("BiT") as GUI and allow separate backup tools (even non-`rsync`) as (non-GUI) backup backend?

2. The backup/restore location is IMHO theoretically independent of the used backup backend. Should this be a generic part of the BiT GUI or configured individually in the backup backend (since some backends have their own implementations of mounting, encryption and deduplication support)?

1. No. Im asking for nothing in the end. it was only if i had a wish free hehe. BiT can be left like it is now. Like described in my 2-3 year old issue, i first wanted to use timeshift. but than found out that timeshift dont allow to store the snapshots/backups on a nfs share for what reason ever (so far i remember, because the dev says rsync dont support soft- and hard links on nfs shares, what isnt true). So i searched further and found BiT. But BiT "disqualified" himself, because back than it was possible to make backups etc, but if i restored the backup, all newer files (after the created backup) was still there. This makes first sense, but so far i remember, back than BiT have/had a option to restore exactly like the backup destination (so, delete all files and folders etc wich dont exists in the backup, like timeshift it does). And this dont worked. So i dont tested if i can use nfs shares as backend.

2. No. BiT should stay like it is, like mentioned. but sure it would be nice if someone could choose for example few options depending on they system for example. If the user have btrfs, ask/reccommend the user to use btrfs (like timeshift). or a option to use borg. i personaly prefer borg (because i wrote a little script my self, there is a little description what problem i had back than. still using today: https://github.com/solisinvictum/borgrestore). So BiT with a borg option/implementation would be really nice/heaven (so BiT handles the creation of the borg repo on destination for example. deliver options from borg for compression, dedublications etc). And best thing is, it is unbeliveable easy to implement borg to BiT or any program. A example how im using it (rsync + borg), is in my repo like said :)

Edit: Read accross my own repo a little. directly from my readme: https://forum.endeavouros.com/t/searching-for-a-real-backup-solution-no-btrfs-or-timeshift/20249/9

Yep. There you can dig your gold hehe. a lot of information what problem i had back than (if it isnt fixed until today).

[aryoda]

@solisinvictum

I have read your experience report about backup solutions and I am wondering if your use case is "system backup" (not only "data backup").

Since your blog article does neither contain the used BiT configuration nor mentions the paths included in the backup I can just guess and did so by looking into your script config:

https://github.com/solisinvictum/borgrestore/blob/275e5d8a815b19dc21b159f37ffaa61c6b5c88da/borgrestore.conf#L4-L25

If your use case is really "system backup/restore" with BiT (= inlcude the root folder) I think this is not the intended use case for BiT to take snapshots of a running system (root folder) because many files are in use and can neither be backed-up nor restored while the system is up (running). This is the perfect domain of imaging tools like clonezilla.

I was searching for a documentation about valid use cases BiT but couldn't find it so far.

We have to improve our documentation by adding supported and non-supported use cases (esp. for BiT root).

[buhtz]

If your use case is really "system backup/restore" with BiT (= inlcude the root folder) I think this is not the intended use case for BiT to take snapshots of a running system (root folder) because many files are in use and can neither be backed-up nor restored while the system is up (running). This is the perfect domain of imaging tools like clonezilla.

This should go into our FAQ because the topic comes up often.

[aryoda]

I will add a FAQ entry for that...

See also #1526, #480, #667

[solisinvictum]

If your use case is really "system backup/restore" with BiT (= inlcude the root folder) I think this is not the intended use case for BiT to take snapshots of a running system (root folder) because many files are in use and can neither be backed-up nor restored while the system is up (running). This is the perfect domain of imaging tools liek clonezilla.

It is no problem to create a full Backup with BiT. Timeshift is doing the same. And it works too. I backup and restored with timeshift or rsync self often without problem. Restoring isnt a problem too.

I had only problem with the handling of excluded files/path like described.

[aryoda]

Closing this since fixed with above PR