I've not used tarsnap before but it doesn't seem to be worth the frustration being caused here. I think rsync works pretty well and it's end to end encrypted over SSH with multiple ways to perform compression.
The wrong way to switch operating systems on your server
51–60 of 77 posts
Re: The wrong way to switch operating systems on your server
#52Why tarsnap when wasabi or backblaze would be significantly cheaper? You can just encrypt by yourselves anyway. Also I run my own personal infra and here’s what I do: * treat servers as cattle, not pets. This is really important. Have mandatory reboots, never be afraid of reboots. * preferably do things with an automation method, I use ansible for n=5 but pick whatever you like * have SOME monitoring. It’s not too ha…
> Have mandatory reboots, never be afraid of reboots.
Yes! It is not a badge of honor to have a server that's been online for 365+ days -- it just means you haven't applied any kernel security updates for a long, long time. :-p
Re: The wrong way to switch operating systems on your server
#53Without a sweat, I recently changed from Ubuntu to NixOS on a server I have access to only via SSH (so mounting an ISO wasn't an option) using[0], so the switch happens live(!) and when you reboot you end up in NixOS. I've also done it to CentOS 7.5, but manually via[1].
It was the case here that backups were not necessary, but it's pretty incredible what's possible when the system configuration is declarative and only /nix and /boot are needed by NixOS to boot. I highly recommend people new to running servers to try NixOS.
[0] https://github.com/elitak/nixos-infect
[1] https://nixos.org/manual/nixos/unstable/index.html#sec-insta...
Re: The wrong way to switch operating systems on your server
#54Wow, that's much more technically advanced than I was as a teenager! Way to go! To print progress with tarsnap 1.0.39, send it a SIGUSR1 or SIGINFO. On FreeBSD, you can do this by pressing ctrl-t. On Linux, you have to use the unfortunately-named `kill` or `killall` command, such as killall -SIGUSR1 tarsnap https://www.tarsnap.com/tips.html#check-current (Note that Tarsnap is not responsible for naming the unix `kill…
"employed by"
Re: The wrong way to switch operating systems on your server
#55> I woke and the backup was finished! I wiped the VPS Just this single line made me scream in horror. Let me get this straight. He launched some backup command, it didn't output anything for hours, he suspected it hadn't done anything, aborted with ctrl-c, and then learned that he aborted it at 90%. Wipes the partial backup, starts again. After _that_ experience, he blindly trusts the result of _the same tool_, blind…
Spoiler: That's not even part of his "lessons learned". I know whom I won't hire for my company IT or devops or whatnot.
> I’m FIGBERT, an Israeli-American high school student
They've got probably half a decade of youthful mistakes to make yet before they'll darken your recruiting door. Give em a break.
(At their age I think I was still bashing on Locksmith to copy AppleII game floppies, and I turned out OK enough to be managing the devops team where I work now...)
Re: The wrong way to switch operating systems on your server
#56I feel like a lot of this article really should be about how bad tarsnap is. Defaults to no progress updates, has no builtin multithreading, has failures around large files, can't backup sym links properly, no builtin way to detect an in progress restore so you have to manually tell it to resume, etc. If tarsnap didn't have a bad UX, this entire article would have instead been 'the time I forgot to backup my .env fil…
I agree. Used to use tarsnap but the speed is garbage.
It’s so bad that actually restoring anything of any size is just not viable.
Re: The wrong way to switch operating systems on your server
#57One big WTF in my mind is the default lack of feedback with tarsnap. The -v should be implicit and automatic , and should need a flag to turn OFF, not on. I mean, that’s just UI/UX 101. _Always_ provide feedback on progress, unless explicitly and intentionally silenced.
Tools that are intended to be used in scripts often have fairly quiet default modes. tar, cp, and many other *nix tools in that general realm tend to only speak up when something goes wrong, at least by default. That said, I'm on your side and I think quiet mode should be the option with a reasonable human-friendly verbosity being default. Or even better, some form of detection of if it's being run interactively vers…
Exactly - it’s very possible to detect of being run interactively and at least provide a hint - or even when Ctrl-C is hit (I know some programs will print the status on ctrl-c and tell you to hit it twice to kill it). At least when exiting and saying 90% give a hint how you could have seen thy without killing it.
Re: The wrong way to switch operating systems on your server
#58These experiences are relatively common, we just don't see writeups that often. Kudos to the author for writing this up. I do disagree with some of the lessons here. You want to switch operating systems on your server? 1. Set up monitoring. If you don't have monitoring already, hack something together with simple scripts. 2. Start up a new server. 3. Migrate services and data from your existing server to your new ser…
I do a variation of this when moving to a new developer machine. I virtualize the previous one and keep it around for a long time.
Re: The wrong way to switch operating systems on your server
#59Why tarsnap when wasabi or backblaze would be significantly cheaper? You can just encrypt by yourselves anyway. Also I run my own personal infra and here’s what I do: * treat servers as cattle, not pets. This is really important. Have mandatory reboots, never be afraid of reboots. * preferably do things with an automation method, I use ansible for n=5 but pick whatever you like * have SOME monitoring. It’s not too ha…
> Have mandatory reboots, never be afraid of reboots. Yes! It is not a badge of honor to have a server that's been online for 365+ days -- it just means you haven't applied any kernel security updates for a long, long time. :-p
> Yes! It is not a badge of honor to have a server that's been online for 365+ days
The badges come at 1000 days and every 500 after that. If you have a minimal kernel, and a limited software set, many kernel security bugs found won't apply to your system and you don't need to reboot for them.
Not that you need to be scared of reboots, and you should probably schedule some reboots so you can be confident your systems can reboot, but you also don't need to be scared of uptime or stability, either.
Re: The wrong way to switch operating systems on your server
#60These experiences are relatively common, we just don't see writeups that often. Kudos to the author for writing this up. I do disagree with some of the lessons here. You want to switch operating systems on your server? 1. Set up monitoring. If you don't have monitoring already, hack something together with simple scripts. 2. Start up a new server. 3. Migrate services and data from your existing server to your new ser…
Yeah I was legitimately confused why there was a problem until I realized that author had installed the new OS to the same server as the old one. I can't understand why that was done. Previously I wouldn't even have called your method of moving services over one by one while keeping the old setup available "best practice" because I thought it was so obvious. I hope the original author realized that this should really be what is learned from the story.