Nextcloud Backup System Idea
-
@DustinB3403 said in Nextcloud Backup System Idea:
@JaredBusch The stated case is, how can I create backups and do so in a fashion that would work.
While using the same Hypervisor and backing up to a separate VM on the same Hypervisor as the host does not create a backup.
Since it isn't detached, I'm sure if I look hard enough I can find several instances of you spouting this.
Even for a lab, this is a bad approach to take and the better approach would be to setup a VPS and do your backups to that as the detached backup and from that push the backups to a cloud if the goal would be to follow the 3-2-1 rule.
I also never stated to not take backups, I implied it was stupid to take backups to the same hypervisor that your production set is made from.
On the contrary, a lab is exactly the place to set up something like this and test processes. That is the entire fucking point of a lab.
Shoving off to a VPS somewhere is a totally different approach that would require different tools.
The tools used when staying within the same network are not the same. Could they be? Sometimes.
I don't know WTF crawled up your ass, but go take a shit and let it out.
-
@JaredBusch said in Nextcloud Backup System Idea:
@DustinB3403 said in Nextcloud Backup System Idea:
@JaredBusch The stated case is, how can I create backups and do so in a fashion that would work.
While using the same Hypervisor and backing up to a separate VM on the same Hypervisor as the host does not create a backup.
Since it isn't detached, I'm sure if I look hard enough I can find several instances of you spouting this.
Even for a lab, this is a bad approach to take and the better approach would be to setup a VPS and do your backups to that as the detached backup and from that push the backups to a cloud if the goal would be to follow the 3-2-1 rule.
I also never stated to not take backups, I implied it was stupid to take backups to the same hypervisor that your production set is made from.
On the contrary, a lab is exactly the place to set up something like this and test processes. That is the entire fucking point of a lab.
But you would never do this for a production workload. So consider the workload as any other and find the issues with the plan, punch holes in it, and realize that the plan may not hold water. A lab is a place to test process, but process needs to be considered before it is tested. One such issue with this process as discussed is if the Hypervisor or Host fails you risk everything.
Shoving off to a VPS somewhere is a totally different approach that would require different tools.
It's the approach that would likely be taken in cases like this where "I only have a 1U in a colo and am looking for ways to protect it".
The tools used when staying within the same network are not the same. Could they be? Sometimes.
I don't know WTF crawled up your ass, but go take a shit and let it out.
-
@DustinB3403 said in Nextcloud Backup System Idea:
Even for a lab, this is a bad approach to take and the better approach would be to setup a VPS and do your backups to that as the detached backup and from that push the backups to a cloud if the goal would be to follow the 3-2-1 rule.
Of course in a real environment it wouldn't be smart to backup to a VM that's on the same hypervisor as the VMs that are being backed up. The goal is practicing a process, which is have a target for backups that are then replicated to
$cloudStorage. The way to achieve this given the hardware I have is to backup to a VM (on the colocated server), then from that VM send copies of the data away.Another, and probably better approach, would be to just backup the data to two different cloud storage providers, or follow your suggestion to backup to a VPS and then push from there. The beauty of a lab is I can tear stuff down and try multiple approaches.
-
@EddieJennings said in Nextcloud Backup System Idea:
Another, and probably better approach, would be to just backup the data to two different cloud storage providers, or follow your suggestion to backup to a VPS and then push from there. The beauty of a lab is I can tear stuff down and try multiple approaches.
This is likely not a better approach. Because the major point of local backup is to have fast recovery.
Without fast recovery, there is less reason to have a local backup.
-
@EddieJennings said in Nextcloud Backup System Idea:
Thinking through RPO / RTO this is what I think is reasonable for this data. I could handle NextCloud not being available for 24 hours as well losing 24 hours worth of data. The initial amount of data that will be stored in NextCloud will be around 1.5 TB. There will likely be far less than an a gigabyte / day of new data created.
All of this implies this is not just a lab, at least not for the long term. look at setting up your systems in a manner which can be easily protected.
Rather than going through the process you stated in the OP.
-
@JaredBusch said in Nextcloud Backup System Idea:
@EddieJennings said in Nextcloud Backup System Idea:
Another, and probably better approach, would be to just backup the data to two different cloud storage providers, or follow your suggestion to backup to a VPS and then push from there. The beauty of a lab is I can tear stuff down and try multiple approaches.
This is likely not a better approach. Because the major point of local backup is to have fast recovery.
Without fast recovery, there is less reason to have a local backup.
Quick is relative when he's stated he can be without this NC instance for 24 hours.
-
@JaredBusch said in Nextcloud Backup System Idea:
@EddieJennings said in Nextcloud Backup System Idea:
Another, and probably better approach, would be to just backup the data to two different cloud storage providers, or follow your suggestion to backup to a VPS and then push from there. The beauty of a lab is I can tear stuff down and try multiple approaches.
This is likely not a better approach. Because the major point of local backup is to have fast recovery.
Without fast recovery, there is less reason to have a local backup.
Exactly. As Scott said, the multiple copies of backups then is more about durability than anything else. Do you really not trust your first cloud provider that much?
Fast recovery would be the main goal I can think of for local backup.
-
@DustinB3403 said in Nextcloud Backup System Idea:
But you would never do this for a production workload. So consider the workload as any other and find the issues with the plan, punch holes in it, and realize that the plan may not hold water. A lab is a place to test process, but process needs to be considered before it is tested. One such issue with this process as discussed is if the Hypervisor or Host fails you risk everything.
You're correct in that risk is the problem with this idea. Part of the point of the thread is to get some other ideas on how to do what I'm wanting -- which you've provided. Backing up to the VM would serve a purpose as I've mentioned. It let me emulate how to do that process, with the exception that the target VM is on the same hypervisor rather than a different hypervisor. What I can take away is that I can design / do the task, and if I'm ever in an environment where I have more than one device with which to work, I can do the same process, but have the backup target on a different device, which is how it should be done.
-
@EddieJennings said in Nextcloud Backup System Idea:
The goal is practicing a process, which is have a target for backups that are then replicated to
$cloudStorage. The way to achieve this given the hardware I have is to backup to a VM (on the colocated server), then from that VM send copies of the data away.Practicing process also requires that you practice developing process and having holes punched into said idea.
-
@DustinB3403 said in Nextcloud Backup System Idea:
@EddieJennings said in Nextcloud Backup System Idea:
The goal is practicing a process, which is have a target for backups that are then replicated to
$cloudStorage. The way to achieve this given the hardware I have is to backup to a VM (on the colocated server), then from that VM send copies of the data away.Practicing process also requires that you practice developing process and having holes punched into said idea.
Only helpful when said holes are valid to the target practice being developed. WHich yours are not.
-
@DustinB3403 said in Nextcloud Backup System Idea:
@EddieJennings said in Nextcloud Backup System Idea:
Thinking through RPO / RTO this is what I think is reasonable for this data. I could handle NextCloud not being available for 24 hours as well losing 24 hours worth of data. The initial amount of data that will be stored in NextCloud will be around 1.5 TB. There will likely be far less than an a gigabyte / day of new data created.
All of this implies this is not just a lab, at least not for the long term. look at setting up your systems in a manner which can be easily protected.
Rather than going through the process you stated in the OP.
It can be tough to fully describe intent in the OP, when the point is discussion. I figured, even for just a lab, it would've been wise to decide an RPO/RTO goal. Rather than just picking some random time for that, I thought through the idea of "if this were production, I could likely handle . . . "
-
@EddieJennings said in Nextcloud Backup System Idea:
@DustinB3403 said in Nextcloud Backup System Idea:
But you would never do this for a production workload. So consider the workload as any other and find the issues with the plan, punch holes in it, and realize that the plan may not hold water. A lab is a place to test process, but process needs to be considered before it is tested. One such issue with this process as discussed is if the Hypervisor or Host fails you risk everything.
You're correct in that risk is the problem with this idea. Part of the point of the thread is to get some other ideas on how to do what I'm wanting -- which you've provided. Backing up to the VM would serve a purpose as I've mentioned. It let me emulate how to do that process, with the exception that the target VM is on the same hypervisor rather than a different hypervisor. What I can take away is that I can design / do the task, and if I'm ever in an environment where I have more than one device with which to work, I can do the same process, but have the backup target on a different device, which is how it should be done.
But you already have the ability to access as many additional hosts as you want. You could even backup to your on-premise desktop or a VPS.
I agree that testing the click-this, input that steps are worthwhile. I disagree in the approach you're looking to take with what has been stated in the OP and hence.
-
@DustinB3403 said in Nextcloud Backup System Idea:
Practicing process also requires that you practice developing process and having holes punched into said idea.
Yep. And you've validated some holes I've considered, but didn't explicitly write in my posts.
