Score:0

Stupid /etc deletion

ru flag

Common problem, many posts about this, I know. I have my hands into debian/ubuntu for the past 20 years. But I did something stupid anyways:

I needed to restore my Let's Encrypt certificates so I moved my "/etc" backup archive to "/root". Untar, moved the certificates back to "/etc/letsencrypt" and tried to remove my "/root/etc" folder. I suppose you see where I am going... Tired, unfocused, I cleared the "/etc" folder instead of the "/root/etc" folder. So mad.

Fortunately I still had the "/etc" incremental backup. I restored everything with the right permissions and ownerships! I managed to restore the vital services "Nginx", "PHP-FPM", ... But I'm kinda worried about the next reboot. Because this backup was performed yesterday but since, I did upgrade from Debian 8 to 9.

Should I reconfigure Grub? Or any other action? Kernel has changed I suppose during the upgrade. I add that this is a dedicated production server, hosted outside.

Thanks a lot,

Axel

Nikita Kipriyanov avatar
za flag
Better restore the system from backup and then redo the upgrade from 8 to 9. Then to 10, then to 11, because it is the current stable release.
Axel avatar
ru flag
Thanks @NikitaKipriyanov, unfortunately this is a production server and unique. What you propose will lead to half a day or a day downtime (if everything goes fine). You think it will not reboot at this point?
djdomi avatar
za flag
the iddue you currently have is, that you also killed your grub and etc, you might ve able to boot or not. better restart from scratch and then remind to use apt-cacher-ng on a proxy if not already using one and a upgrade should be fine, remind to do a snapshot between your works whatever dangerously you wanted to do. `remember that only a reboot csn give you the knowledge of truthful power`
Axel avatar
ru flag
I hear you @djdomi, backups are daily and incremental. I just did this huge mistake right before the backup starts. So there is no way to rebuild the grub config ? With a dpkg-reconfigure or grub-update or so?
Nikita Kipriyanov avatar
za flag
There could be no general recommendations. If this server was unique, you'll have to rebuild its configuration somehow. We can't help you in details, because just figuring out the details could be an enormous field of work. Another clever idea might be to create a *clone* of the said machine from the last working backup, perform the same actions — upgrade, but of course don't do anything hazardous, and then after it seems to work correctly, use it as an aid to restore the configuration of the production machine.
Axel avatar
ru flag
Another idea I just had: upgrade from 9 to 10. That will reset many settings correctly normally, including the right grub and dist version. Very hazardous. To be tested :-) Thanks for your answers guys
Nikita Kipriyanov avatar
za flag
This certainly coincides with your stated desire to have least downtime and that this is the production server. Either put on your pants or take off the cross :) Also you're on your own from now: Debian manual states explicitely the system must be in a consistent state before upgrade can take place. If something wasn't fixed, you can have problems in the future.
djdomi avatar
za flag
`!IMHO!`, basically you can restore them from the latest backup. Since the upgrade will never touch my modified configs, but restore them at a point -as Nikita correctly stated - it is a oneway solution - you should sync the data from now, take the weekend and restore the machine, take snapshot upgrade, take snapshot upgrade, etc go-on with dist-upgrade and verify the situation... it Will be the faster way in my point - or Start from Scratch and Migrate them :)
Axel avatar
ru flag
I hear you, thanks
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.