I still don’t understand the backup retention.
Suppose I use the smart retention policy (" 1W:1D,4W:1W,12M:1M").
I have a folder with two files, each file 100 MiB. They are backed up. The remote storage will be about 200 MiB.
I then delete one of these files. At what point in time will my remote storage usage drop to approx 100 MiB?
Hello
as I’m very lazy, I have asked a friend for advice. You’ll see the exchange in the attached images.
As he is a bit shy, I have masked the name.
Please note that I am not endorsing this advice, I am not competent enough to judge. Maybe it’s good. Maybe not so much. Possibly other people will chime in.
Welcome to the forum @bladiebla
In about 12M because you gave that as the longest timeframe to be protected.
Backup protection provides ability to restore an old file even if file got deleted.
If you’re certain you want a file gone now, it’s possible to force it to be purged.
What was confusing to me was the last sentence in “Over time backups will be deleted automatically. There will remain one backup for each of the last 7 days, each of the last 4 weeks, each of the last 12 months. There will always be at least one remaining backup.”
If the file is gone after 12M, how is there one remaining backup?
You might be mixing concept of backup versions and specific files, as evidenced by the two words.
A backup is a snapshot store of whatever files existed at that date.
The line just means you’ll have a snapshot, not that your file is in it.
Files are in backups that saw them. If file is deleted, and backups have aged away, that file is gone.
EDIT:
Restore menu chooses a backup version. Tree it makes shows files.
In the first step, select the restore point from which you want to restore some files by selecting a date and time behind Restore from. Each restore point will list all files and folders included in the backup exactly as they were at the listed timestamp.
So the “remaining backup” says you’ll have one you can choose from. Chances are that it’ll be recent.
Thanks for the detailed reply, it is very much appreciated. Sorry for my late response, life caught up with me for some time.
So let me try to be explicit to see if I understand. If you think it’s useful I’m happy to contribute something like this to the manual.
1 jan 1980: I have two files, each 100 MiB. The backup version created that day will have both files init.
2 jan 1980: Nothing changed on disk. A new backup version is made, but it will be the same as the one from 1 jan.
(…)
31 may 1980: A last backup is made with two file as I will delete one of the files tomorrow.
1 june 1980: I delete one of the files. A new backup version is made, which will contain only one file. There are now two unique sets: one from jan 1st (with two files) and one from june 1st (with one file).
2 june 1980. Nothing changed. A new backup version is made, but it will be the same as the one from 1 jun.
(…)
1 june 1981: A new backup version is made, but it will be the same as the one from 1 jun. The version from 31 may 1980 is expired and will be removed. It will now be impossible to restore the file that I deleted on 1 jun 1980.
I forgot the history, but it apparently helped some, so I’m going to start by responding to what’s right here.
If no files have changed, Duplicati will not upload a backup set. If the backup data is used to verify that a backup was executed, this option will make Duplicati upload a backupset even if it is empty.
so unless you enable that option, you probably won’t get a version, with no change. You’ll get a log though.
This same comment applies to 2 june 1980. It’s not a “unique sets” thing, 2 june should create no version.
If there’s a missing “Nothing changed”, then it should be so-the-same that there would be no version made.
If the last version that knew about a file has been allowed to be deleted, restoring that file gets very difficult. Sometimes it’s possible, through laborious specialized methods that work better if compact hasn’t run yet.
Space at the destination isn’t reclaimed immediately on version delete, but delete makes some destination stored blocks no longer needed for the known versions, and compact will eventually remove wasted space.
Before a compact runs (check logs), there’s a window of opportunity to undelete files from “wasted” space.
It helped a lot! I feel very grateful to have so many persons that patiently explain all kinds of topics to me.
Ah, okay, that explains that missing part.
Here I indeed simplified a bit. So it isn’t “always impossible to restore”, but at least “you should not count anymore on the ability to restore”. With that modification to my example (and the comment above about new versions to be made or not when no changes are found), I think my example is correct, right?
First wording was closer, and would be fine if it said “impossible for Duplicati”, but one can go around it.
If you want to see how difficult it gets to attempt to retrieve data from a deleted version without a dlist file which basically has the path names and reassembly directions for the version from date in its file name:
