New answers tagged

1

I have never been hit by one of these nasty cryptolocker variants, but short of having a backup of files, let it be via snapshots or some other method, is the only protection you can have. Also whoever told you that the snapshots have a performance penalty, is not totally right. Yes, taking a snap shot takes away some resources, but depending of the size ...


3

There are several reasons why this may have failed: /var/www/html could actually be a symlink to somewhere else in your filesystem (try ls -la /var/www/ to see if there is a line like html -> /foo/bar/html. If /dev/sda3 was mounted during either of your dd processes, the filesystem may have been corrupted so that you don't see that file any more. Using ...


0

since you have the 600gb empty you can mount your current HD and copy its files to the 600gb ! or you can make a new backup using dd+gzip and you will have chance to restore your hard drive without problems of loosing space. if you want to do that from your current runing os : mount your current hd (since it is an ext4 it can be mounted on ...


1

I don't know anything about BackupNinja but if it (like most backup programs) can write to stdout then you can do something like this: echo foo | su -g users nobody bash -c 'umask 177; cat >/tmp/newfile' ls -l /tmp/newfile -rw------- 1 nobody users 4 4. Feb 09:39 /tmp/newfile


0

The owner of the files that are generated by a process are the same as the owner of the process itself. When your backup tool runs as root than the owner of the backup-tar will be root. The solution to the problem should be, that you run the backup process as user and not as root. I guess you use something like a cron job to do your backup. So Refer to the ...


0

So long story short, this is the best way I have found to achieve this, in case someone else is interested: find /mnt* -type d -name snapshots > dir.list; \ tar -czpf - -T dir.list | ssh user@host "openssl aes256 \ -out /mntc/backups/snapshot.tgz.enc -salt -k 'secret'"


2

I don't agree with the squashfs recommendations. You don't usually write a squashfs to a raw block device; think of it as an easily-readable tar archive. That means you would still need an underlaying filesystem. ext2 has several severe limitations that limit its usefulness today; I would therefore recommend ext4. Since this is meant for archiving, you ...


2

SquashFS is a compressible read-only filesystem that fits your requirements well, has been in the kernel for a few years, and is already widely used (e.g., in LiveCDs). The latest documentation for the userspace tools is on GitHub. From the documentation: Squashfs is a highly compressed read-only filesystem for Linux. It uses either gzip/xz/lzo/lz4 ...


1

You'd probably be better served by a compressed filesystem. There are ways of compressing various Linux filesystems (FUSE can do it), but since this will be read-only once you've created it, you might consider squashfs. You create the filesystem with mksquashfs. Linux has had squashfs in the main kernel since 2.6.something, so it should work from pretty ...


0

I use rsnapshot-1.4.1 and install it manually from the tar.gz source by doing ./configure make install By default it will install a template rsnapshot.conf.default file under /usr/local/etc/ and the rsnapshot perl script under /usr/local/bin/ you need to do 2 things regarding the configuration file: cp /usr/local/etc/rsnapshot.conf.default ...


0

What about aliases? Typing alias at the command line you will see all defined aliases. I'd suggest adding something like: alias rm='rm -i' Define it in ~/.bashrc, (so you can remove it in future or change it to suit your needs.) [mal@localhost ~]$ touch 123 [mal@localhost ~]$ rm 123 [mal@localhost ~]$ touch 123 [mal@localhost ~]$ rm -i 123 rm: remove ...


1

If you remove the 'w' bit, you can't accidentally overwrite whatever you removed the 'w' bit from. If that's a directory, that means you can't add or remove files from that directory; if that's a file, that means you can't change the file. Downside of that method, however, is that you lose data (IMO, file permissions are part of your backup data). An ...


2

It would generally avoid all the sudo and deliberately inhibiting yourself access to your files - it will likely cause you problems and possibly be so annoying you will just override your own protection mechanisms anyway. I would instead use trash-cli which behaves like a desktop type trashcan where you can recover your file later if you make a mistake. ...


0

Changing directories' permissions to 555 (or 550, or 500...) will prevent you from deleting or creating files inside them. Changing files' permissions to 444 will prevent you from modifying them. (You really need to combine both operations, since many editors will create a new file when "modifying" an existing one, which effectively means that you can end up ...


1

if you want to backup your home directory, then you need not necessarily to be in recovery mode. That would only be needed if you want a complete snapshot of your system disk. Just don't change files in the home directory while the backup is running. Try this: xorriso -for_backup -outdev /dev/sr0 -blank as_needed -map "$HOME" / Have a nice day :) ...


0

rsync -avr --delete-excluded --include=*.txt /source /* /destination May help your needs. Let me know.


0

Fixing this should be possible, and it roughly resembles Arch Linux installation process (disclaimer: I might be mistaken about some steps, please comment if you're in trouble). First of all, boot with your live CD/DVD/USB. Then, mount your partition (everything as root!): mkdir /mnt/ubuntu mount /dev/sda2 /mnt/ubuntu Then, backup all you might need from ...


2

Checkout ntfsclone. I believe that's what you're looking for. From the man page: ntfsclone will efficiently clone (copy, save, backup, restore) or rescue an NTFS filesystem to a sparse file, image, device (partition) or standard output. It works at disk sector level and copies only the used data. Unused disk space becomes zero (cloning to sparse ...


0

If sdb is partitioned, you could backup just the partition with the data of interest. For example: sudo dd if=/dev/sdb1 of=rpi-backup-image bs=4MB


1

You need to treat /dev/sdb2 as either a raw partition or as a filesystem, not as both. It appears as though you created a filesystem on it at one point and mounted it at /media/ravi, but as soon as you piped tar or cpio output directly to /dev/sdb2, you ruined the filesystem. Either write to a file on the filesystem, or treat it as a raw device that you do ...


0

You should use the --confirmation option from the tar command. For example: $> tar xvf --confirmation x.tar.gz


0

Yes it (at least the tar program) will overwrite existing files (it won't append anything): $ mkdir x $ echo hello >x/file $ tar cvfz x.tar.gz x x/ x/file $ echo world >x/file $ tar xvfz x.tar.gz x/ x/file $ cat x/file hello Since you've rewrote your question the answer is that the existing files .htaccess, a.html, b.html, c.html will be replaced ...



Top 50 recent answers are included