• 5 Posts
  • 15 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle






  • I have been thinking the same thing.

    I have been looking into a way to copy files from our servers to our S3 backup-storage, without having the access-keys stored on the server. (as I think we can assume that will be one of the first thing the ransomware toolkits will be looking for).

    Perhaps a script on a remote machine that initiate a ssh to the server and does a “s3cmd cp” with the keys entered from stdin ? Sofar, I have not found how to do this.

    Does anybody know if this is possible?


  • Yes. Fair point.

    On the other hand, most of the disaster senarios you mention are solved by geographic redundancy: set up your backup // DRS storage in a datacenter far away from the primary service. A scenario where all services,in all datacenters managed by a could-provider are impacted is probably new.

    It is something that, considering the current geopolical situation we are now it, -and that I assume will only become worse- that we should better keep in the back of our mind.





  • Well, the issue here is that your backup may be physically in a different location (which you can ask to host your S3 backup storage in a different datacenter then the VMs), if the servers themselfs on which the service (VMs or S3) is hosted is managed by the same technical entity, then a ransomware attack on that company can affect both services.

    So, get S3 storage for your backups from a completely different company?

    I just wonder to what degree this will impact the bandwidth-usage of your VM if -say- you do a complete backup of your every day to a host that will be comsidered as “of-premises”



  • First of all, thanks to all who replied! I didn’t think there would have been that many people who self-host a SSO-server, so I am happy to see these replies.

    As a side-note, I have also been looking into making the setup more robust, i.e. add redundancy. For a “light redundant” senario (not fully automatic, but -say- where I have a 2nd instance ready to run, so I just need to adapt the DNS-record if it is needed), can I conclude from the “makeing a backup” question, that I just need to run a 2nd instance of postgres and do streaming-replication from the main instance to the backup-instance ?

    Or are there other caviats I haven’t thought about?




  • For me, the first goal is to simply understand the setup. I now have been able to create a setup with two frontend jvb-instances and one backend. In the end, the architecture setup of a jitsi-server is quite nicely explained, and -by delving a little bit into the startup scripts of the docker-based jitsi setup, you do get some idea of how things fit together.

    From a practicle point of view, I think I’ll go for the basic setup (1 backend, 2 frontends) natively on two servers, and -if the backend server would go down- just have a dockerised backup-setup ready to go if it would be needed.

    Thanks!