New answers tagged

0

As this question has many different answers, the following list should combine the suggestions into one comprehensive list: Under most circumstances you want to backup these: /home/ for user data and configuration /etc/ for system wide configuration files /var/ contains a mix of directories you usually want to backup and those you don't want to backup. ...


0

Maybe try modifying /usr/lib/python2.7/dist-packages/duplicity/tempdir.py (or wherever that file is at your system) to add a more specific exception handler, it seems to do just this: except Exception: log.Info(_("Cleanup of temporary file %s failed") % util.ufn(file)) pass A more specific error ...


1

You have two good options, foremost and extundelete. extundelete - Is your first choice, it can recover the files with NAME! foremost - is ugly, and recovery files by the sector number and type, but there is a better chance to recover. It will try to work even if the partition is damaged or with bad blocks, or of course in the entire disk if there is no ...


1

As I understand it, your remote storage is exposed as a filesystem. I don't use btrfs myself but I assume the snapshots are equivalent to one large "full backup" file followed by a number of smaller "incremental" files. On that basis I'd still go with rsync because it's restartable. You can't use its snazzy delta differences algorithm unless there's an ...


0

This is also an experience based response rather that one backed up by hard data. I find that when deleting many files in similar trees with a lot of cross links it seems faster to delete isolated subtrees in parallel. Let me try and explain with a diagram: topdir1 |-a1 |-b1 |-c1 topdir2 |-a2 |-b2 |-c2 topdir3 |-a3 |-b3 ...


0

In my experience, the best way to speed up rsync+hardlink based backups was to decrease the number of files you have. A large number of small files slows down rsync a lot. If you can organize your data in such a way so that your mostly small-file, mostly read-only directories get tarred up, you should see a significant speed up in your backup script. (With ...


1

The df is reporting a small number because you're mostly deleting directories, which are relatively small. Also, depending on the filesystem, changes to directories and changes to the number of links to a file are journaled and/or synced to the disk immediately, since they're critical for fault recovery, and thus slower. That's actually a testament to the ...


0

I can't see how your use of xargs in this way is anything but slow. My manpage says -P is the number of processes and -n is the number of arguments. There's no special value for -P0, so that's likely ignored (or, if honored, you get zero processes, which would explain 24 hours of nothing!). And -n1 ensures you get one exec(2) for each filename, which is ...


0

Pass the --numeric-owner option to tar either when making the archive or when extracting it (or both). This causes the files to be extracted with the same UIDs and GIDs that they were archived under, regardless of user names on the system where you extract. Since you're restoring the user database alongside the rest, the files will end up owned by the ...


1

A list of installed packages and dotfiles in your home is a good bet. The management of dotfiles is a sort of art, check https://dotfiles.github.io/


1

If you did it correctly then all your changes are in your $HOME. Just copy that $HOME folder around and your done. If you don't want to copy the entire folder then ~/.local/config is a good place to start, but your better off just copying over the entire folder.


0

lftp mirror command does not remove files by default, only if you add -e or --delete options. To confirm that, use mirror --dry-run option.


1

dd in your example does full system image backup, byte to byte mirroring /dev/sda to /dev/sdb. However you must be sure that /dev/sdb if equal or larger size disk. Modern systems do not permit plain copying like that because they embed some other unique identity information like UUIDs into volumes; there maybe issues with LVM setups, on-disk cryptography ...


0

If you have the output of rsnapshot available, you can safely repeat the rsync command that it used. You do not (and should not) delete hourly.0 if you're going to do this. For example, on one of my systems this is (almost) what gets run by rsnapshot, so this could be copied and pasted and rerun: /usr/bin/rsync -avzS --delete --delete-excluded ...


0

The solution to the problem is, We killed the rsync process which was initiated by vzdump (there were two) Once we kill rsync, the vzdump process was exited after that, resume/stop/start the VM didn't work vzctl chkpnt VEID --resume (this command helped to start the VM)


0

Step 4 after Anthon's first 3 work: Try tar --rsh-command=/usr/bin/ssh -cv -f ltouser@remote:/dev/st0 Or whatever is your ssh path. Most system tar's compile in /usr/bin/ssh as rsh-command default. But sometimes the default is /usr/bin/rsh instead. And rsh might not exist.


3

tar can cope with partial archives after splitting. When you try to restore part of such an archive, it will skip over whatever it can't use at the start, and tell you about any partial file at the end; everything in between will be restored properly. You can instruct tar itself to split archives as it creates them, using the tape length options; see Create ...


1

Well it is always best to do a fresh install on empty partitions or otherwise you'll keep lots of unneeded files all over the place. There is no magic solution to know where you saved your files. They may be in /home but you could have saved then all over the place. It may be a good idea to also backup the list of installed packages for future ...


0

Two suggested answers are specific to Linux. Here's a suggestion, sticking to POSIX: #!/bin/sh find "$@" -type f |\ xargs du -s |\ awk 'BEGIN {total = 0;} { total += $1; } END { print total; }' Alternatively, you could attempt to work around spaces in pathnames (still POSIX): #!/bin/sh find "$@" -type f -exec du -s {} + |\ awk 'BEGIN {total = 0;} { ...


1

If you have GNU find, you can make it print the file sizes. find /source ! -type d -printf '%P %s\n' Sort the output to get deterministic output. If the filenames contain newlines, it's possible to get the same sorted output for different arrangements, but that's not going to happen unless deliberately engineered. comm -3 <(find /source ! -type d ...


3

Simply feed it a list of everything you DO want counted using --files0-from find -type f -print0 | du --files0-from=-


-1

I believe what you are looking for is --max-depth. So for example. If you wanted to calculate the disk usage of a directory without all of its subdirectories this is how it would be done. du [directory name] --max-depth=1 If you wanted to find the size of its subdirectories too just increase the depth. I found a link that gives a lot of information on ...


4

If you don't mind moving the files... You could do this by moving the files into a git repository, and symlinking them to their old locations; you'd end up with ~/gitrepo/somedir/otherdir/file1 moved from ~/somedir/otherdir/file1 ~/gitrepo/otherdir/somedir/file2 moved from ~/otherdir/somedir/file2 a symlink from ~/somedir/otherdir/file1 to ...



Top 50 recent answers are included