Tag Info

New answers tagged

2

The important things are your data! Programs (and the rest of the system) can always be re-installed from scratch from DVD and your distro's repositories. That said, it may be a good idea to back-up /etc with your configurations (if you've done many changes) and perhaps /usr/local if you've installed many packages locally. The important stuff is /home ...


1

If you only have a root partition you should make a full backup of that (and if you have e.g. a separate /home you should back that up as well). The most easy way to do so is use the -x/--one-file-system option of rsync so that you can recurse from / downward without including temporary/virtual filesystems like /run/lock or /dev The first time this will of ...


0

In any case I'd stop working on the device being used as soon as possible to avoid any disk writes, and boot into a dedicated recovery OS, like SystemRescueCd, which is a Live-CD so you can mount your disk read-only in order to prevent further data loss. Those distros include a lot of recovery tools mentioned by others, and you can install most missing. I ...


0

Consider using Backup Exec for Linux. Not free, but that'd cover your management needs. What are the "Windows people" doing for a backup solution? Are you allowed to purchase the same kind of solution for the Linux side? BTW, logrotate can be used to rotate out your backup copies. There are a number of great discussions in stackexchange regarding the use ...


0

You can use imapsync for this. You can get the source from fedorahosted.org imapsync page. Zimbra Guide to imapsync has good documentation about this subject.


0

"cp -pr" should do the job. The "r" option in "pr" should take care of both subfolders and any hidden files/directories.


1

This already does a full backup. The contents of the directories that are excluded (such as dev, run, etc) are created in run time and should not be backed up. Copying boot folder will not override your boot sector, so that is fine. Using rsync here is the correct method as rsync can work within the same system or remotely and it will also only update ...


-1

I'm running Backintime with a NAS DS414 with DSM 5. It requires one little modification on the NAS and a good configuration. To my surprise updates remove my modification. So, keep it in mind when you perform an update. If you want to backup your data on a share named backups located on volume1. You should create a new share named volume1 located on ...


0

If you know which processes are writing to files in that directory, you can freeze them using kill -SIGSTOP <pid>, do your backup then resume the processes with kill -SIGCONT <pid>.


0

To my knowledge, atomicity of such a transaction cannot be guaranteed by ext4 in itself without cooperation from the application that is accessing the data concurrently. Using some snapshot mechanism in an underlying device mapper won't work either, since you'd basically need to unmount the filesystem (or at least remount-ro) in order to obtain a consistent ...


2

The README in that directory states that scripts in that directory are only called once on poweroff (and not on reboot). With a simple test program #!/bin/bash LOG=/root/backup.log date >> $LOG echo $* >> $LOG I noticed that one time the program was actually called twice, once without a parameter and once with the parameter 'stop'. I have ...


0

I'd go for the dd option. Because that makes sure you have a "snapshot" like state of the disk including the master boot record and your partition table. If restoring you can write the image right back to the disk, without the need for partitioning or fiddling with grub. The "somewhere" should be any fast and reliable storage you can mount into the rescue ...


0

Why not zfs send your snapshots to a remote ZFS machine? I use a simple bash script for this: #!/usr/local/bin/bash # ZFS Snapshot BASH script by Shawn Westerhoff # Updated 1/14/2014 ### DATE VARIABLES # D = Today's date # D1 = Yesterday's date # D# = Today less # days date Y=$(date -v-1d '+%m-%d-%Y') D=$(date +%m-%d-%Y) D1=$(date -v-1d '+%m-%d-%Y') ...


7

I would create a separate specific passwordless SSH key for this purpose. On the server side, you can set limits to what that key can be used for and where it can connect from, so that even if someone gets hold of the key, they would still not be able to use it to do something malicious. The way to limit the key is to edit the authorized_keys file on the ...


0

Have a look in your cron Configuration file. Maybe your cron-job is run as an specific user which does not have access to everything. Also its a clever idea to write log-files so you can see what exactly your script does when run by cron.


1

Take a look at the keychain package. I'm not sure if it will do what you want, but it does cache the keys in memory in some fashion. And it does not require X to work.


4

You can use SSH keys which have no passphrase. If you don't like that idea then you can create a key file without passphrase and put it into a RAM disk. Thus after a reboot you would have to log in manually in order to prepare the system for batch SSH usage by entering the passphrase and providing the new file. In the ssh calls you would have to provide ...


1

The "solution" you mention is a really bad one (it can't deal with weird file names for example) and completely unnecessary. Just use diff directly: diff -r "$PATH1" "$PATH2" That will recursively (-r) compare the directories and report whether files are present or missing. For example: $ tree . ├── dirA │   ├── file1 │   └── file2 └── dirB └── ...


2

I think that ntfsclone might be really helpfull here. As mentioned in the manuall: "...ntfsclone can be useful to make backups, an exact snapshot of an NTFS filesystem and restore it later on..." ntfsclone is part of the ntfs-3g package.



Top 50 recent answers are included