XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Feedback on immutability

    Scheduled Pinned Locked Moved Backup
    52 Posts 9 Posters 10.3k Views 11 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • florentF Offline
      florent Vates 🪐 XO Team @rtjdamen
      last edited by

      @rtjdamen said in Feedback on immutability:

      @florent so this does mean it will never work when a forever incremental is used?

      you can't have a immutable forever backup without having a infinite length, and an infinite

      It may be possible only if we release the constraints.
      The immutable script could release the immutability , merge the disks, but that means : the immutability will be lifted from time to time, and the responsibilities of the immutability script will be greater, and we'll need a way to track the vhd to merge and transmit the information to the immutability script

      1 Reply Last reply Reply Quote 0
      • A Offline
        afk @florent
        last edited by

        @florent said in Feedback on immutability:

        @rtjdamen for the immutability to be useful, the full chain must be immutable and must never be out of immutability

        the merge process can't lift/ put back the immutability , and increasing synchronization between process will extend the attack surface.

        immutability duration must be longer than or equal to 2 time the full backup interval -1
        the retention must be strictly longer than the immutability .

        for example, if you have a full backup interval of 7 a retention of 14 and immutability duration of 13 , key backup are K, delta are D. Immutable backup are in bold . unprotected chain are striked

        KDDDDDDKDDDDDD worst case, only one full chain protected
        KDDDDDKDDDDDDK
        KDDDDKDDDDDDKD
        KDDDKDDDDDDKDD
        KDDKDDDDDDKDDD
        KDKDDDDDDKDDDD
        KKDDDDDDKDDDDD best case almost 2 full chain protected

        I have not tried backups in XO yet but I'm really looking forward to test the immutability as we have it configured on all veeam backups at work.

        Just to be sure, the XO immutability "agent" only does its immutability check by date right ?
        Would it be possible to consider the entire backup chain related to the oldest immutable restore point instead ? This would prevent misconfigurations from the user that result in insecure backup chains.

        florentF 1 Reply Last reply Reply Quote 0
        • florentF Offline
          florent Vates 🪐 XO Team @afk
          last edited by

          @afk the agent is as dumb as possible

          also if you encrypt the backup, the agent will need to decrypt the metadata to detect the chains, thus having access to the encryption key, which need getting the encryption key out of XO and transferred to the immutability agent

          I think it will be easier to provide more feedback on the immutabiltiy backup, XO has access to the chain , and / or alert when something seems to be strange

          1 Reply Last reply Reply Quote 0
          • V Offline
            vkeven
            last edited by vkeven

            Where is the doc for these ? edit ok right here https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/immutable-backups , with V**m there is an option for immutability when you add the S3 bucket directly so its look like its only a flag sent at bucket creation and using the versionning/compliance feature

            florentF 1 Reply Last reply Reply Quote 1
            • florentF Offline
              florent Vates 🪐 XO Team @vkeven
              last edited by

              @vkeven we don't have ( for now) the feature to create bucket directly from XO. Also I think it is more secure if XO don't know at all the credits of the bucket admin

              1 Reply Last reply Reply Quote 0
              • olivierlambertO Offline
                olivierlambert Vates 🪐 Co-Founder CEO
                last edited by

                Indeed, because if XO is compromised, then it could disable immutability.

                V 1 Reply Last reply Reply Quote 0
                • V Offline
                  vkeven @olivierlambert
                  last edited by

                  @olivierlambert We tried adding compliance( prevent any file manipulation for X period) directly into bucket but XOA could not do his backup job correctly and the logs are full of access denied probably because of file merging or manipulation refused , so how we should do this ?

                  R 1 Reply Last reply Reply Quote 0
                  • R Offline
                    rtjdamen @vkeven
                    last edited by

                    @vkeven same problem here, we decided not to proceed with this as it would never work with an incremental delta without doing a full every few weeks. We are going to handle this with s3 and synology internal features.

                    1 Reply Last reply Reply Quote 0
                    • olivierlambertO Offline
                      olivierlambert Vates 🪐 Co-Founder CEO
                      last edited by

                      Thanks for your feedback, we'll discuss internally if there's any other possible approach (and I'm not sure).

                      1 Reply Last reply Reply Quote 0
                      • V Offline
                        vkeven
                        last edited by

                        So what is the deal with these guy ?

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post