Talk:System backup
command (and script) handle rsync errors poorly (such as caused by .gvfs)
This page is very useful but things could be improved. I used the script currently here for a recent backup but rsync failed saying
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1070) [sender=3.0.9].
Unfortunately, I could not tell which files were not transferred because the offending output had long since scrolled past the terminal window and even beyond my terminal's large history buffer. A dry run of rsync (with the -n
switch) allowed me to track down the culprit, which turned out to only be .gvfs
in my home directory. This is a GNOME thing (Gnome Virtual File System) that uses FUSE which is a separate file system. Turns out that rsync fails on this directory when the command is run as root (but oddly it works if ran by the owner).
I've never used Arch (some day) but Arch users can run GNOME so the .gvfs
issue should affect them too. Reading forums and threads about rsync failing over .gvfs
suggests that rsync's -x
switch (to avoid cross filesystem files) does not fix this and the only way to fix it is with an --exclude
. As this appears to be a common problem, an exclusion of /home/*/.gvfs
should be added to the list.
The bigger problem is the way the script handles errors. Ideally, it should at least log rsync errors to a separate file so that the details can be easily read (rather than just the last error message which will usually not contain enough information). I hacked together a quick solution for me based on
(cmd | tee stdout.log) 3>&1 1>&2 2>&3 | tee stderr.log
but there are many possibilities here depending on whether you want stdout, stderr, or both logged. A "perfect solution" must also be careful that asynchronous output doesn't scramble the order the information in the log files.
Anyway, these are just two suggestions for improving this script. Cheers, Jason Quinn (talk) 20:40, 11 January 2015 (UTC)
- Removed the script, the one-liner seems to have other issues. -- Alad (talk) 19:47, 25 February 2015 (UTC)
- Hi, Alad and Lahwaacz. Thanks for looking into this. Alad, might removing the script be throwing out the baby with the bath water? It was a valuable if imperfect script. Also, the note just saying
/home/user/.gvfs
is problematic. Readers may wrongly interpret it to mean to exclude just their home directory's GVFS subdirectory when they must exclude all GVFS subdirectories. I'll add a parenthetical remarks about that. Using/home/*/.gvfs
is a quick pragmatic solution that should work most of the time. A full solution would require a command that generates a list of all users' home directories to exclude .gvfs from that. Jason Quinn (talk) 23:09, 4 March 2015 (UTC)
- The current wording here is still problematic. Users must exclude the
.gvfs
subdirectories or rsync reports errors. The current wording just suggests to skip "unimportant" subdirectories, a suggestion which does not prepare the user for seeing "uninvestigatable error" reports (because scrolled too far) after backing up over night. Jason Quinn (talk) 11:10, 20 March 2015 (UTC)
- The current wording here is still problematic. Users must exclude the
- Better. Cheers, Jason Quinn (talk) 18:34, 20 March 2015 (UTC)
Single command expanded
About [6], if you pass the original, shorter --exclude
argument to echo it appears to expand to the same, longer command. See [7]. Not sure what went wrong here... -- Alad (talk) 19:41, 25 February 2015 (UTC)
- The longer version has portability in mind: not all shells allow brace expansion, including, for instance, older versions of BASH. Plus, although it is longer, it is less "syntaxy". This makes it easier to read and easier to spot the pattern to generalize by adding one's own particular excludes. It may be a good idea to prefer the longer version for these reasons. Jason Quinn (talk) 23:25, 4 March 2015 (UTC)
- There are probably many different Bash-like conventions on the wiki (see e.g. Help:Reading), so the ArchWiki is not meant to provide "portable" information. I'd just assume that users of alternative shells are aware of the differences, or at least they can find the solution to problems as they arise. -- Lahwaacz (talk) 17:33, 18 March 2015 (UTC)
- In light of the "Does the given command really work?" thread, the assumption about the users of alternative shells are aware of the problem is questionable. Although this wiki is intended for Arch users, that does not necessitate using the most compact version of a command that works under the default Arch shell. Both ways (the long and the short) would work under Arch and are in that sense both the "Arch way" of doing things. An Arch user could equally well be using a shell for which the command does not work, therefore this issue is independent of "Archiness". It's really just an issue of whether the mere shortness of the compact version is worth allowing some people to improperly use the command for their backups. One possibility is to use the long version and put in the notes box a bullet about the shortened syntax for some shells. Jason Quinn (talk) 11:38, 30 March 2015 (UTC)
- It's acceptable. One other comment: this page is ranked highly by Google for common search terms related to backup and rsync. This suggests that the page will get significant traffic from people looking to learn how to backup on linux in general, not just limited to Arch, due to the article title. In any case, I think it's an important point when knowing the readership of the article. Jason Quinn (talk) 19:56, 30 March 2015 (UTC)
fstab example
Re [9], it probably makes sense to have a note in place which reminds why (multiple) existing fstab entries should be commented out. That, or add something to the ¨With a single command" section concerning restoring backups to multiple partitions. -- Alad (talk) 18:54, 13 October 2016 (UTC)
-x flag
An aside in #command (and script) handle rsync errors poorly (such as caused by .gvfs), but point of its own, rsync -x
would replace most of the excludes? When you look at findmnt output, it should behave as expected [10]
I suppose it makes sense if you have multiple partitions with user data, such as /home
. Cf. Talk:Full_system_backup_with_rsync#fstab_example. We could clarify on this regard; more generally, give more points for people to construct their own rsync command, rather than build an article around a single one. -- Alad (talk) 20:51, 16 October 2016 (UTC)
Directories to backup
I expect /root
be a directory to backup, as /home
is. It should be listed in the introduction. Is there a reason for it not to be?
Audeoudh (talk) 10:08, 7 May 2020 (UTC)
Snapshots and /boot partition hook time
Why do example use `PostTransaction` and not `PreTransaction`? I backup my `/efi` in pre-transaction to have restore options if something messed UP with initram kernel images or new loader configs. Am I doing it wrong?
—This unsigned comment is by Insomnes (talk) 16:00, 12 July 2023 (UTC). Please sign your posts with ~~~~!
- Special:Diff/706009 says "It should be post as we would want to keep new boot files in the new snapshot". If you want to backup old files, you can use the
--backup-dir
rsync option, for example. -- andreymal (talk) 16:19, 12 July 2023 (UTC)