Recently, Improvements on speed in general and mount in particular have been done and some more are on the way. You might want to try out the latest beta (which should be already faster especially for large files within your repo) or this optimization:
Fatal: unable to open repo at /etc/yum.repos.d/_copr_copart-restic.repo: ReadDir: open /etc/yum.repos.d/_copr_copart-restic.repo/keys: not a directory
Okay, just select the dir not the actual repo.
sudo restic restore --target=/tmp/restore --include=/usr/share/squirrelmail/config/config.php b55535fc --repo “/etc/yum.repos.d”
Fatal: unable to open config file: Stat: stat /etc/yum.repos.d*/config*: no such file or directory
hmm…I see the file but the computer is telling me there is no file.
Is there a repository at the following location?
I see the /config getting added in there. Possible issue.
repository e72f1d68 opened successfully, password is correct
found 2 old cache directories in /root/.cache/restic, run restic cache --cleanup to remove them
restoring <Snapshot b55535fc of [/home/orca] at 2020-07-20 11:29:09.163974804 -0700 PDT by email@example.com> to /tmp/restore
Restore directory is empty =(
The file should be in there no?
[orca@orcacomputers restore]$ ll
Or have you not started using restic yet?
Been doing backups to my external hard drive for a while now.
I have no idea what is in your backups. Try restic ls b55535fc | less to show the contents of the backup. Run man less if you aren’t sure how to use the less pager (it will let you scroll through the output, which is useful if there are hundreds of files in the backup).
restic ls -l -r /run/media/orca/DataCabinet b55535fc | grep ‘squirrelmail/config’
Fatal: unable to open repo at /run/media/orca/DataCabinet: ReadDir: open /run/media/orca/DataCabinet/keys: permission denied
sudo restic ls -l -r /run/media/orca/DataCabinet b55535fc | grep ‘squirrelmail/config’
[sudo] password for orca:
enter password for repository:
This is a file in the directory with path /usr/share/squirrelmail/config/. This is completely outside of your home directory (~), assuming your home directory isn’t somewhere in that path, which it most likely isn’t.
This backs up only your home directory, not e.g. /usr/share/squirrelmail/config/. Usually your home directory is something like /home/<username>, mine is /home/rawtaz.
This means that you have never backed up the file you are looking for. Please verify this by showing us the output of echo $HOME. If the beginning of the path that this command outputs doesn’t match /usr/share/squirrelmail/config/ then you simply never backed this file up in the first place, and that is why it is not in your backup and that is why it can obviously not be restored from the backup.
Honestly, and I say this not to be rude but to make you understand - you totally need to educate yourself on the basics of using your operating system. You seem very lost in what even the most basic commands do or how to structure them, what the files in your filesystems are, what the different paths in your filesystem are, and which paths cover what (for example, / will cover ~ so if you back up / you don’t need to also back up ~)
So yes, the answer to your question is that you can just add / at the end of your backup command, but if you want to back up everything you can just replace the ~ with / instead since that’s the more proper representation of “everything”.
Note that you’ll probably want to exclude certain directories, there’s a lot of files that aren’t relevant to back up at all, e.g. some runtime and system files. There should be a bunch of topics about backing up (and I think also restoring) full Linux filesystems or similar, feel free to search a bit to perhaps find them. There’s a lot of people backing up their entire system.
The blessing in disguise isn’t so much due to an actual disguise, you should know that if you back up ~ this will not include /. There’s nothing disguised here at all
Apologies if you feel offended, but I’m just bringing up the elephant in the room. Hopefully for the best - if you continue like this it’s just a matter of time before you run into some really big problem or data loss or vulnerability due to not knowing how your system(s) work. Noone wants that to happen!
you’ll probably want to exclude certain directories, there’s a lot of files that aren’t relevant to back up at all, e.g. some runtime and system files
10-4 I am seeing that now. ETA 17 hours to do a backup, total size 128 TiB, all 12 cores on my cpu are at capacity so I will stop it and back up my main software and /var/www for all webcontent. Then if I ever edit a configuration file or something I will back up just that file.
Thanks again, you helped me on my other thread a while back too. Much appreciated.
Note that you also probably want to add --one-file-system to your backup command.
Linux has a number of virtual filesystems that you DO NOT want to back up (such as /proc and /sys, and even /dev on modern distros). This calls back to what @rawtaz said about learning the basics of your system. You don’t actually want to back up everything visible from / since some of that stuff doesn’t actually exist on disk.
In particular, if you happen to have a removable USB drive mounted when the backup runs, the backup will also grab the contents of that drive.
--one-file-system prevents restic backup from “crossing filesystem boundaries” which means it will stay only within the filesystems explicitly listed as arguments. If / is the only storage volume in your system, then restic backup -r ... --one-file-system / will work. But if you have e.g. /home as a separate volume, then you would need to list both (/ /home) on the command line.
There is no one-size-fits-all answer here. You need to know your own system.
No, you don’t want to back up “just that file.” After restic backup has finished backing up this mountain of data, future runs will only back up chunks of files that changed and you should see follow-up backups complete very quickly.
If you back up only files that changed by hand, then you will not have a complete snapshot of everything anymore. If your disk suddenly dies and you want to restore everything from a backup, you’ll have to restore multiple backups in pieces to restore the system. Letting restic take complete snapshots (with its deduplication) should be pretty quick and gives you a single snapshot of the entire state of the system. (The snapshot will just share a lot of data with the prior snapshot.)