I'm still parsing all you said, but in addition to showing me a better testing technique with "file:///" you hit on two of what I thought were my next concerns: how to test for the presence of the partition before starting a backup and using a snapshot to deal with open files during a backup. The first will challenge my scripting skills and the second may well come out in the wash as I explore the difference between dmsetup and cryptsetup. I seem to recall that cryptsetup may actually just be a frontend for dmsetup and either may let me create a snapshot. Both are career enhancing opportunities.
Obviously, I concur that having filesystems come and go is never good, but I'm trying to accommodate all possible scenarios. My partitions are encrypted and not mounted at boot up because my file server is unattended extensively and I want to protect against theft. Disaster planning accounts for theft and I can restore to a newly created machine. Testing for partition presence solves these problems. I'm still not sold on a cloud server for files that get unencrypted at logon. Storing my locally encrypted duplicity volumes on cloud storage is as much as I can swallow at this point.
I have other hardening ideas too, but they usually run into the brick wall, ".... if someone is root on your system, you have bigger problems." Future projects and learning experiences.
Thanks again.
hey Anonymous,
comments inline
On 22.08.2023 00:00, duplicity--- via Duplicity-talk wrote:
> Hi all, I am executing a somewhat complex test plan which I will share if you need it to give advice, but here is the short version first. I generally leave my partitions mounted and have a partition by partition backup that runs nightly.
>
> What happens if the following timeline occurs?
>
> 1) Full backup, some number of incrementals, each with a given file changed.
> 2) LUKS partition is inadvertently dismounted or system boots w/o me manually mounting partitions.
generally not good if filesystems disappear willy-nilly. should that happen during backup i am not sure how duplicity would react. if it happens before you can test if your luks volume is mounted beforehand. see below.
> 3) Scheduled backup occurs on raw mount point.
> 4) LUKS partition is mounted on raw mount point.
> 5) Changed file is deleted.
> 6) Next scheduled backup is run.
>
> At this point the changed file from #1 is no longer in the catalogue because of #3. I have tried restoring by timestamp previous to #2, but that older file isn't available. I see two options:
use date/time strings and `list-current-files` to list backup contents, grep through the result for the file you are looking for. unfortunately listing cannot be limited to some path
e.g.
:~$ duplicity collection-status file:///tmp/dupbkp2
Last full backup date: Sat Jul 22 11:33:50 2023
Collection Status
-----------------
Connecting with backend: BackendWrapper
Archive dir: /home/ed/.cache/duplicity/171e404808f99be98d870571c9d6c6ec
Found 0 secondary backup chain(s).
Found primary backup chain with matching signature chain:
-------------------------
Chain start time: Sat Jul 22 11:33:50 2023
Chain end time: Tue Aug 22 15:45:52 2023
Number of contained backup sets: 2
Total number of contained volumes: 2
Type of backup set: Time: Num volumes:
Full Sat Jul 22 11:33:50 2023 1
Incremental Tue Aug 22 15:45:52 2023 1
-------------------------
No orphaned or incomplete backup sets found.
:~$ duplicity list-current-files --time=2023-07-22T11:33:50 file:///tmp/dupbkp2
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sat Jul 22 11:33:50 2023
Sat Jul 22 11:29:48 2023 .
Sat Jul 22 11:29:53 2023 dirA
Sat Jul 22 11:30:17 2023 dirA/a
Sat Jul 22 11:30:00 2023 dirA/dirB
Sat Jul 22 11:30:10 2023 dirA/dirB/b
> 1) Run a backup when I mount the partition in #4, but since some of my partitions are large and my jobs run 4-7 hours I would like to find another way.
not needed. simply check if your mounted file system is available/mounted. use dmsetup to test and skip the backup if it is not there.
>Also, #5 could happen prior to that backup completing.
well, changing the file system during backup is a bad idea in generell. backup snapshots or when nobody changes stuff.
>
> 2) I found the following post, but don't understand "... If you had the
> exact time of deletion and moved any incremental backups out of the way
> that had occurred since then, it would be possible to do it manually."
>
> I have the file timestamp of each of the edits in the incremental.
>
> How do I move the incremental in #3 "out of the way" so I can restore from backups prior to backing up the raw mount point?
you really do not need to. using the `--time` parametr has the same effect.
good luck.. ede/duply.net
_______________________________________________
Duplicity-talk mailing list