Hot answers tagged

3

According to its man page, ddrescue should be called like this: SYNOPSIS ddrescue [options] infile outfile [logfile] So, in your specific case, ddrescue /dev/sda /mnt/hdd/backup.hdd; no if= or of=.


3

First of all, the the overall power consumption will be likely the same or more if you artificially slow down the backup process. Simply because the total number of operations is the same and if the process takes longer, the cpu consumes less peak power but over a longer time. For example, if the process runs for 10 s at peak power of 200W this will consume ...


3

Best practice would be to not only unmount but additionally disconnect the backup. You presumably expect your backup to protect you in case (for example) someone accidentally downloads a cryptolocker. Or someone breaks in (compromises) your system. Or a weird system crash that corrupts filesystems. Or a lightning surge that fries all your electronic devices ...


3

rm --one-file-system should do the trick. --one-file-system when removing a hierarchy recursively, skip any directory that is on a file system different from that of the corresponding command line argument Source: http://man7.org/linux/man-pages/man1/rm.1.html


2

looks like you backed up to ~user/home/user/backup on the target machine. try (notice the extra slash signalling an absolute path) duplicity full /home sftp://user@hostname.com//home/user/backup or alternatively duplicity full /home sftp://user@hostname.com/backup . ..ede/duply.net


2

To do nothing if the file already exists in the destination tree (regardless of any metadata), pass the option --ignore-existing to rsync. rsync -a --remove-source-files --ignore-existing /var/www/domain/media/ /var/www/domain/bak/


2

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 ...


2

One approach would be to use parallel compression in order to use all of the cores of your system and therefore reduce the compression time. It won't reduce the load on your system, but it will be loaded for a shortest amount of time ! You can find how to do it in this Q/A for example : utilizing-multi-core-for-targzip-bzip-compression-decompression For ...


1

One solution is to make a union mount of B and C with C as the write branch. Then the problem reduces to copying from A to B+C only files missing on B+C, which can be done with rsync -a --ignore-existing /A /B+C For the union mount, one possibility is unionfs-fuse. unionfs-fuse -o cow /C=RW:/B=RO /B+C Or unionfs: mount -t unionfs -o dirs=/C=rw:/B=ro ...


1

debsums can help you out quite a bit. The oft-quoted debsums -ce will list configuration files which have been changed, from the pool of tracked configuration files; so it's not a complete solution. Instead, you should run debsums -e, and ignore any file which is marked "OK". Anything else — which includes files listed by debsums as "FAILED", and files not ...



Only top voted, non community-wiki answers of a minimum length are eligible