Borg-BackUP-GUI

Borg-BackUP-GUI copied to clipboard

So that you can select the max size backups for some folders will have and if the max size is reached,then the oldest backups get deleted.

However, I believe that this would ultimately delete security-relevant data, and there have already been some discussions about this on Borg Backup itself.

It is possible, however, to delete parts in the "Delete" area, although this is not recommended, as you should keep your BackUP as extensive as possible - but if you are 100% sure what you are doing, you can also use it to reduce the size of your BackUP.

But first I would advise you to mount your current BackUP in the BackUP section and take a close look at what you want to send into nirvana forever.

Then I have a better idea,that if max size is reached,that nothing gets deleted and nothing new gets backuped to that location and you get a warning notification.

For example, you want a maximum size of 19.5 GB for e.g. a cloud storage of 20 GB; if this is in danger of running out, then before a backup the message STOP YOU NEED MORE STORAGE SPACE FOR A BACKUP ON THIS MEDIUM! should come up?

Did I understand you correctly?

yes

A simple warning, which would probably be issued if the frame volume could be exceeded, is too inaccurate for this, as it would too often display an incorrect warning for large data with little change.

For this, there would be possible solutions such as:

1. Analysis of the need based on the existing backup, and the new or changed data, and then comparing them. The time required is likely to be identical to a COMPLETE initial backup process, i.e. extremely long.

2. Matching the new or changed data for the backup, and assessing the data type for its approximate compression ratio. For this, one would have to enter the most common file types in a control calculation list, but as soon as new or unknown file types were added, this analysis would become extremely inaccurate! The time required is likely to be identical to a COMPLETE initial backup process, i.e. extremely long.

3. Analysis Backup to an alternative local medium, and after falling below the frame volume, transfer to the target volume. This should take at least 3 times as long as a normal deduplication (required for this backup).

4. Or something absolutely new that I haven't thought of yet, and that also meets Borg's claim (high speed).

Let's see if I or someone else can think of something, but of course such a function could be useful.