A
Athreya aka Maneshwar
Guest
Hello, I'm Maneshwar. Iβm building LiveReview, a private AI code review tool that runs on your LLM key (OpenAI, Gemini, etc.) with highly competitive pricing -- built for small teams. Do check it out and give it a try!
Moving a server β whether itβs to a new VM, a different provider, or fresh hardware β feels simple until something goes wrong.
A missing backup, an overlooked DNS TTL, or an untested restore can turn a routine migration into an outage.
Here are the essential steps you should always take before moving a server.
Takeaway: A smooth migration is about preparation, not speed. Backups + documentation + rollback = confidence.
LiveReview helps you get great feedback on your PR/MR in a few minutes.
Saves hours on every PR by giving fast, automated first-pass reviews.
If you're tired of waiting for your peer to review your code or are not confident that they'll provide valid feedback, here's LiveReview for you.
Continue reading...
Moving a server β whether itβs to a new VM, a different provider, or fresh hardware β feels simple until something goes wrong.
A missing backup, an overlooked DNS TTL, or an untested restore can turn a routine migration into an outage.
Here are the essential steps you should always take before moving a server.
1. Take Verified Backups
- Full system backup: Image or snapshot the disk (provider snapshots,
rsync,dd, or tools like Velero if Kubernetes). - Service-level backups: Dump databases (
pg_dump,mysqldump), export configs (tar /etc/), and archive important app data. - Verify: Try restoring a database dump or untar an archive on a test VM. A backup isnβt real until you can restore it.
2. Inventory Whatβs Running
- List services:
systemctl list-unit-files --type=service | grep enabled - Installed packages:
dpkg --get-selections > packages.list(Debian/Ubuntu) orrpm -qa > packages.list(RHEL). - Custom configs: Identify changes in
/etc/, crontabs, and application config files. - Dependencies: Make note of external services (SMTP, S3, APIs, OAuth providers).
3. Prepare DNS & Networking
- Lower DNS TTLs (e.g., 300 seconds) at least 24β48h before migration, so you can flip traffic quickly.
- Check firewall rules on the new server (ports, UFW, security groups).
- Plan rollback: Know how to switch DNS or proxy settings back if needed.
4. Secure Credentials & Access
- Collect SSH keys, tokens, passwords stored safely (preferably in a password manager or secret store).
- Test that you can log in to the new server with proper user permissions.
- Disable root logins via password on the new host before making it public.
5. Dry Run on the New Host
- Clone the environment: Create the same users, packages, configs, and mount points.
- Migrate data:
rsync -avz --progressto copy over, ideally using snapshots or with minimal downtime. - Smoke test: Start the main services (e.g., database, web server, API) and confirm they respond.
6. Document Everything
- Write down the old β new mapping (hostnames, IPs, services).
- Note the migration steps and commands used.
- Keep track of any workarounds or fixes you applied during the move β youβll thank yourself later.
7. Rollback Plan
If something fails, you should be able to:
- Point DNS back to the old server.
- Re-enable the old VM/service.
- Restore backups in minutes, not hours.
Checklist Before Hitting βSwitchβ
- [ ] Verified backups exist and are restorable
- [ ] DNS TTL lowered
- [ ] All configs/services inventoried
- [ ] New server tested and secure
- [ ] Rollback plan ready
Takeaway: A smooth migration is about preparation, not speed. Backups + documentation + rollback = confidence.LiveReview helps you get great feedback on your PR/MR in a few minutes.
Saves hours on every PR by giving fast, automated first-pass reviews.
If you're tired of waiting for your peer to review your code or are not confident that they'll provide valid feedback, here's LiveReview for you.
Continue reading...
