How to make a secure copy of /etc/letsencrypt?

My domain is:

Hi guys,

I am very new to the lovely world of Let’s Encrypt and also with using the terminal. I managed to get the SSL certificate installed successfully, but at the end, the Terminal indicates:

Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.

I don’t understand how to make a copy. Can anyone explain to me?

1 Like

A command like this should be enough:

cd && tar -czf etc-letsencrypt$(date +%s).tar.gz /etc/letsencrypt


Note that this is assuming that you are root. (A non-root user won’t have the permissions to read some of the contents of /etc/letsencrypt.)

By the way, I’m not sure whether that backup advice is useful to everyone who uses Certbot. We’ve certainly had some people on the forum for whom it would have been useful (because they deleted /etc/letsencrypt when something was misconfigured, and then ran into rate limit problems) but for some people’s use cases it seems like we might not have gained much from this advice.

I appreciate @kato.von.katz’s conscientiousness in wanting to follow the advice here. Most software’s advice to make backups is probably ignored most of the time!

1 Like

Indeed, tar will probably complain if you try that command as non-root.

I agree. A lot of the time is easier to start from a new account key. (By the way, do accounts get purged? IE, some time after their last certificate expires?)

This doesn’t probably apply to people with more than 50 certs on one registered domain name.

1 Like

I logged in as a root user and copied the exact command in the terminal. But I get this message:

tar: Removing leading `/’ from member names

I am not sure what to do with this.

Thank you @schoen, I am quite the conscientious one indeed ;). My background is datascience, but now I need to get myself acquainted with a deeper understanding of computer and digital science for a project I am working on. It helps me to really understand what I am doing, to be able to learn.

The idea is that the files in your tar backup have names like etc/letsencrypt/renewal instead of /etc/letsencrypt/renewal. The advantage of that is that you extract this later, it won’t automatically try to put it back under /etc but instead will extract into an etc subdirectory of the current directory that you’re in when you extract it. That is useful to avoid unexpectedly overwriting system configuration in /etc and to give you an opportunity to inspect the backup contents before installing them.

This behavior is automatic when creating a tar archive of any file or path beginning with a / (an absolute path gets converted into a relative path).


The most useful advice on this I’ve ever been given is something along the lines of

the command man accesses the manual, type man man and hit return to read how it works.


PS: don’t forget to save your new .tar.gz on a different machine. :smiley:


You’re a pro, I can tell :wink:

This is however not a secure backup. Probably best to encrypt it too.


And now you have another private key that you might want to take a secure backup of…

It’s possible to encrypt stuff by means of passphrases and the sorts.

There are various ways to ensure that important parts of your system are backed up securely. The method using tar which is suggested in this thread is useful, but if you want to be really thorough about backing up, it helps to have a dedicated backup server. For example, between my colleague and I we have about five or six servers, one of which uses rsync to mirror the other servers on a nightly basis, and then, to supplement that, we use BackupPC (which is in most distros) to do full weekly backups and daily incremental backups of the client areas of our servers, as well as directories such as /etc/. The beauty of BackupPC is that it stores multiple backups up to a specified age, so if you screw up your configuration you can go back to a previous setup with ease. I have used it to rescue a badly corrupted live server after it suffered a bit of overzealous upgrading.:slight_smile:
The backup server communicates with the live servers using root logins with private/public key negotiation. Obviously, if some scoundrel gets root access to the backup server, the whole network is endangered. The solution to that one is probably to have vpn connections between the live servers and the backup server which can be off the internet.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.