|
|
|
|
|
|
by lucw
1023 days ago
|
|
|
Given how prevalent remote editing workflows have become (VScode remote, I'm sure there are others), I 100% agree with this advice. If you're working on some projects on a remote VM, just store your project files there. It's of course critical to have a backup workflow. I have a bunch of development VMs on a baremetal hetzner proxmox instance, which is completely provisioned using Ansible. Many years ago, I experimented with all sorts of syncing mechanism from my windows desktop to a remote linux VM and the sync lag was just unbearable. I'm much happier when the files live on the development VM. I kind of went overboard and tried to plan for a disaster recovery plan for those development VMs, even though there's not really a very strict SLA required. I can provision those VMs using ansible, but any work in progress which wasn't pushed to github is at risk. To address that, I've got hourly rsync jobs of my home directory replicating to a rsync.net account in Zurich (why Zurich ? gives me the lowest latency from the hetzner server in Germany). I then asked rsync.net to enable 48 hourly snapshots on that account (with additional weekly, monthly). It has become essentially impossible to accidentally lose data and I feel very confident working for days on a git feature branch just committing locally, or perhaps not even committing, given i've got those hourly snaphots. My bare metal server could vaporize and i'd be back up and running in hours. Even if the hetzner datacenter was hit by a nuclear weapon, I would instantiate a VM on any cloud provider, provision it with ansible and be back up and working within hours. I've spent WAY too much time working on my little disaster recovery scenario but it's been insanely fun. |
|
|