Re: Recommended Linux Backup
lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. Rsnapshot is great: http://rsnapshot.org/howto/1.2/rsnapshot-HOWTO.en.html
Re: Recommended Linux Backup
Tony Nelson wrote: On 09-11-01 02:01:18, lrhorer wrote: I don't see any mention of that venerable *nix utility, dump. Other than not looking like a mounted filesystem and possibly the sheer size of the data, dump should fulfill your requirements. I thought about dump, but I did notthink it would stop when a volume is full and prompt for another volume (at least not if the volume is a hard drive). dump normally stops when the media is full (see `man dump` for details and other options), and can either just pause or run a script. I back up semi-manually to DVD via a temporary file, with this command: # dump -0 -L xxx -b 32 -B 4590200 -f /tmp/dvd /mnt/point -0 Full dump -L Label -b Blocksize -B Set the size of the output tape -f Output file Well,OK. Still, dar better suits my requirements. You'd certainly want to rotate between several dump sets for redundancy. No, I'm gong to be doing differential backups. The bckuip array added tot he offline storage is enough redundancy. Well, if you say so. There is no such thing as too many backups, but yes, I have enough redundancy. That would mean more hard drives. It might make sense to also dump to DVDs, just to have a different failure mode. You're kidding,right? Back up the data to more than 900 Dual Layer DVDs? Admittedly they are cheap, but... no, thanks. It depends on the consequences of data loss. If they are severe, there should have several live copies at different locations and providers or at least two offline copies, preferably one with Then I would use multiple hard drive sets. Hard drives cost as little as $.073 per Gigabyte, can read and write upwards of 75 MB/sec, and can store up to 2 TB (soon 3 TB) in a space 1 x 3.5 x 6. By comparison, DVDs cost about $.11 per Gigabyte, usually cannot read or write more than 10 MB/sec, and take up easily 5 or 6 times the space per Terabyte. completely different failure modes. On the other hand, if data loss is of little consequence, then sure, one copy is enough. You aren't reading what I am writing, and are assuming much. First of all I already have at least TWO copies of all my data, even the least significant. Both of these copies are on fault tolerant RAID arrays. Secondly, any more than ordinarily important data is also backed up with multi-generation copies on local hard drives. All critical data is stored in no fewer than four geographically diverse locations. This backup strategy will simply augment an already robust set of backups, and provide geographic diversity for the individually less important but massively voluminous videos on the arrays. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lrhorer wrote: You're kidding,right? Back up the data to more than 900 Dual Layer DVDs? Admittedly they are cheap, but... no, thanks. It depends on the consequences of data loss. If they are severe, there should have several live copies at different locations and providers or at least two offline copies, preferably one with Then I would use multiple hard drive sets. Hard drives cost as little as $.073 per Gigabyte, can read and write upwards of 75 MB/sec, and can store up to 2 TB (soon 3 TB) in a space 1 x 3.5 x 6. By comparison, DVDs cost about $.11 per Gigabyte, usually cannot read or write more than 10 MB/sec, and take up easily 5 or 6 times the space per Terabyte. ... and DVDs can not be reused as often/reliably as hard disks. - -- Johannes Three nations have not officially adopted the International System of Units as their primary or sole system of measurement: Burma, Liberia, and the United States. http://en.wikipedia.org/wiki/Si_units -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkru35wACgkQC1NzPRl9qEVGywCdEzu0ICeJq/D4I4DH0OfxYrZk j2IAnA/1rZJmWuu4Qw6sC6Hb3VjwcMgs =X90C -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On 09-10-31 09:11:29, Johannes Wiedersich wrote: [nothing here -- I'm late to this thread] lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source olution which will do the following: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. I don't see any mention of that venerable *nix utility, dump. Other than not looking like a mounted filesystem and possibly the sheer size of the data, dump should fulfill your requirements. You'd certainly want to rotate between several dump sets for redundancy. That would mean more hard drives. It might make sense to also dump to DVDs, just to have a different failure mode. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
I don't see any mention of that venerable *nix utility, dump. Other than not looking like a mounted filesystem and possibly the sheer size of the data, dump should fulfill your requirements. I thought about dump, but I did notthink it would stop when a volume is full and prompt for another volume (at least not if the volume is a hard drive). You'd certainly want to rotate between several dump sets for redundancy. No, I'm gong to be doing differential backups. The bckuip array added tot he offline storage is enough redundancy. That would mean more hard drives. It might make sense to also dump to DVDs, just to have a different failure mode. You're kidding,right? Back up the data to more than 900 Dual Layer DVDs? Admittedly they are cheap, but... no, thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On Thursday October 29 2009 5:14:44 pm lrhorer wrote: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. tar will do 1, 2, and 4. It might be able to do 5. Tar will *NOT* do 1 2. If tar reaches the nd of a tape volume, it prompts for another volume (it knows how to handle an EOT). When writing to a file, if the need of the volume is reached, tar aborts. Since tar does not maintain an index at all, it cannot do either 4 or 5. How will you reconcile requirement 3 with requirement 2? That is, if you have multiple target volumes that may not all be mounted, how will the user to able to see and interact with his or her backups? If you Many archive utilities create indices of their archives which are stored on media other than the backup media (or in addition to it). Enterprise level software like Amanda and Bacula use a database like MySQL to maintain their indices. Others use a simple file. When dealing with backups for hundreds, or even thousands of hosts, a database approach is essential. In much smaller systems like mine, a simple file based set of indices is fine. There is nothing new or unusual about any of my requests. I was just looking for some experienced advice. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
Dne, 01. 11. 2009 08:21:45 je lrhorer napisal(a): Many archive utilities create indices of their archives which are stored on media other than the backup media (or in addition to it). Enterprise level software like Amanda and Bacula use a database like MySQL to maintain their indices. Others use a simple file. When dealing with backups for hundreds, or even thousands of hosts, a database approach is essential. In much smaller systems like mine, a simple file based set of indices is fine. What's your take on jar, zip, and lzh? Just an idea, I'm not even sure they're all ported to linux; even if they are, they may not be free software ... -- Regards, Klistvud Certifiable Loonix User #481801 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On 09-11-01 02:01:18, lrhorer wrote: I don't see any mention of that venerable *nix utility, dump. Other than not looking like a mounted filesystem and possibly the sheer size of the data, dump should fulfill your requirements. I thought about dump, but I did notthink it would stop when a volume is full and prompt for another volume (at least not if the volume is a hard drive). dump normally stops when the media is full (see `man dump` for details and other options), and can either just pause or run a script. I back up semi-manually to DVD via a temporary file, with this command: # dump -0 -L xxx -b 32 -B 4590200 -f /tmp/dvd /mnt/point -0 Full dump -L Label -b Blocksize -B Set the size of the output tape -f Output file You'd certainly want to rotate between several dump sets for redundancy. No, I'm gong to be doing differential backups. The bckuip array added tot he offline storage is enough redundancy. Well, if you say so. That would mean more hard drives. It might make sense to also dump to DVDs, just to have a different failure mode. You're kidding,right? Back up the data to more than 900 Dual Layer DVDs? Admittedly they are cheap, but... no, thanks. It depends on the consequences of data loss. If they are severe, there should have several live copies at different locations and providers or at least two offline copies, preferably one with completely different failure modes. On the other hand, if data loss is of little consequence, then sure, one copy is enough. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On 09-11-01 02:21:45, lrhorer wrote: On Thursday October 29 2009 5:14:44 pm lrhorer wrote: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. tar will do 1, 2, and 4. It might be able to do 5. Tar will *NOT* do 1 2. If tar reaches the nd of a tape volume, it prompts for another volume (it knows how to handle an EOT). When writing to a file, if the need of the volume is reached, tar aborts. ... Use the -L option to set the tape length in KiB, along with the -M option to tell it to use multiple tapes. See `info tar`. You should probably not be writing to a filesystem, but rather directly to the device file. I don't know if tar will handle that on its own or will need the -L option. tar won't be much use for restoring single files or directories, though. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
Paul E Condon wrote: On 20091030_010001, lrhorer wrote: Alex Samad wrote: On Fri, Oct 30, 2009 at 01:37:51AM +, Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Or have a look at rdiff-backup This doesn't sound to me as if it fits the bill, either. It sounds closer than rsync, but I didn't read anything about changing drives or maintaining an index. Rather, it sounds to me as if it merely creates directories with diff files on them on a single remote target. This strategy won't work when one's targets are much smaller than the array being backed up. I haven't seen any 20 TB drives for sale, so this backup and restore has to span multiple target drives, all but one of which are offline at any given time. I can't remember the details of your original post, but I remember reading it. Then please go back and read it. Given your responses to several suggestions, I suggest that you should reconsider rsync, but not in the way that you seem to have been doing. I use rsync as for the core functionality of a backup system that I have implemented with a few dozens lines of bash scripts. My backup system is very compact and does exactly what I want for a cluster of four hosts. I didn't offer it, because it doesn't do what you want, and, frankly, I remembered your specifications as being poorly thought out. They are not poorly thought out. Rsync simply will not work, period: 1. When the device to which rsync is writing is full, rsync does not pause and ask the user to mount a new device. This could be worked around by using a script to break up the backup into chunks smaller than the physical size of each drive, but that would defeat the whole purpose of using rsync. It also destroys the ability to perform incremental backups. 2. In order to create the list of files to be archived, rsync compares the list of files in the source medium with the list of files in the target medium, copying any missing files to the target. Since in this case the mounted target will never contain more than 2TB or at most 3TB of files, rsync will inevitably try to copy the other 20 or 30 TB of files every time. It has no way to look up the contents of the 10 or 15 offline hard drives. I think there are a lot of different ideas as to what a backup system should do. It was a useful learning experience for me to write my own. My reading of your responses is that it might also be a useful learning experience for you to write your own. If you embark on such a project, I think you should not start from scratch with a C++ compiler, only. Rather you should take rsync as a functioning, debugged module that you can incorporate into your system to handle the great bulk of the low level detail work. But I would fault rdiff or tar, or some other well known software as a starting point. I do nothave the time, resources, or inclination to undertake such a project. I have thought about it, but at this juncture it is just not practical. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. Given that no-one came up with a simple suggestion that fulfills your requirements and none of the large number of backup packages available seems to fit the bill, I think that Paul's suggestion to change your requirements was not inappropriate. If I were you, I'd buy an usb hub and housings/adapters for all the usb disks required for the backup. Then I'd combine them to a lvm or raid0 and use *rsync* or a similar tool to backup the system to all disks attached at once. The only other /practical/ option that /I/ can think of is to buy another machine similar or identical to the production one and use that for backup, again using rsync or a similar tool. YMMV. NB: Have you thought about how much work and how long it will take to *verify* your backup, if it is spread over so many disks, each attached individually? (I strongly recommend to verify one's backup occasionally.) - -- Johannes Three nations have not officially adopted the International System of Units as their primary or sole system of measurement: Burma, Liberia, and the United States. http://en.wikipedia.org/wiki/Si_units -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkrsN4EACgkQC1NzPRl9qEXzywCfXYNd9GToJP9bH2U2A16tUnlR 5wQAn0IZf8e97X8yzWnSIJMISskq6RMi =Uv8G -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On Thursday October 29 2009 5:14:44 pm lrhorer wrote: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. tar will do 1, 2, and 4. It might be able to do 5. How will you reconcile requirement 3 with requirement 2? That is, if you have multiple target volumes that may not all be mounted, how will the user to able to see and interact with his or her backups? If you plan on having all the target volumes connected at once, you might as well create a raid array or use lvm. Not only will it remove requirement 2, but it will have lower overhead and can provide some redundancy. Of course, if you remove your requirement for removable drives, lvm would be an excellent solution that would do everything that you want. MM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Recommended Linux Backup
lrhorer wrote: Since in this case the mounted target will never contain more than 2TB or at most 3TB of files, rsync will inevitably try to copy the other 20 or 30 TB of files every time. It has no way to look up the contents of the 10 or 15 offline hard drives. I found Backup Recovery, Inexpensive Backup Solutions for Open Systems [1] to be helpful. My needs are ~400 GB, so rsync, tar, gzip, and an external 1.5 TB drive work for me. For 30 TB and/ or a catalog tapes model, I'd suggest looking at Amanda [2] and Bacula [3]. HTH, David [1] Curtis Preston, 2007, Backup Recovery, Inexpensive Backup Solutions for Open Systems, ISBN:978-0-596-10246-3, http://oreilly.com/catalog/9780596102463/ [2] The Advanced Maryland Automatic Network Disk Archiver, http://www.amanda.org/ [3] BaculaR - The Open Source Network Backup Solution, http://www.bacula.org/en/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
Alex Samad wrote: On Fri, Oct 30, 2009 at 01:37:51AM +, Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Or have a look at rdiff-backup This doesn't sound to me as if it fits the bill, either. It sounds closer than rsync, but I didn't read anything about changing drives or maintaining an index. Rather, it sounds to me as if it merely creates directories with diff files on them on a single remote target. This strategy won't work when one's targets are much smaller than the array being backed up. I haven't seen any 20 TB drives for sale, so this backup and restore has to span multiple target drives, all but one of which are offline at any given time. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On Thu, Oct 29, 2009 at 06:14:44PM -0500, lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. I'm not sure if it'll do everything you're looking for, but you might want to investigate BackupPC. It's designed to backup to a single hard drive, but it has an archive feature which allows you to copy a single backup to a removeable drive (or tape). It pools files from all of the hosts it backs up, and optionally compresses the files. Its web interface makes each snapshot look like a complete backup. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. I haven't had to maintain this kind of backup so I can't really answer this question, but you may want to look at Amanda, Bacula, and BackupPC, since these are more sophisticated alternatives to rsync. But to tell you the truth, I do not think they really satisfy all your requirements. Stefan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
On Fri, Oct 30, 2009 at 01:00:01AM -0500, lrhorer wrote: Alex Samad wrote: On Fri, Oct 30, 2009 at 01:37:51AM +, Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Or have a look at rdiff-backup This doesn't sound to me as if it fits the bill, either. It sounds closer than rsync, but I didn't read anything about changing drives or maintaining an index. Rather, it sounds to me as if it merely creates directories with diff files on them on a single remote target. This strategy won't work when one's targets are much smaller than the array being backed up. I haven't seen any 20 TB drives for sale, so this backup and restore has to span multiple target drives, all but one of which are offline at any given time. your right, I saw the ribs/rsync reference and worked off that -- It would be a mistake for the United States Senate to allow any kind of human cloning to come out of that chamber. - George W. Bush 04/10/2002 Washington, DC signature.asc Description: Digital signature
Re: Recommended Linux Backup
On 20091030_010001, lrhorer wrote: Alex Samad wrote: On Fri, Oct 30, 2009 at 01:37:51AM +, Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Or have a look at rdiff-backup This doesn't sound to me as if it fits the bill, either. It sounds closer than rsync, but I didn't read anything about changing drives or maintaining an index. Rather, it sounds to me as if it merely creates directories with diff files on them on a single remote target. This strategy won't work when one's targets are much smaller than the array being backed up. I haven't seen any 20 TB drives for sale, so this backup and restore has to span multiple target drives, all but one of which are offline at any given time. I can't remember the details of your original post, but I remember reading it. Given your responses to several suggestions, I suggest that you should reconsider rsync, but not in the way that you seem to have been doing. I use rsync as for the core functionality of a backup system that I have implemented with a few dozens lines of bash scripts. My backup system is very compact and does exactly what I want for a cluster of four hosts. I didn't offer it, because it doesn't do what you want, and, frankly, I remembered your specifications as being poorly thought out. I think there are a lot of different ideas as to what a backup system should do. It was a useful learning experience for me to write my own. My reading of your responses is that it might also be a useful learning experience for you to write your own. If you embark on such a project, I think you should not start from scratch with a C++ compiler, only. Rather you should take rsync as a functioning, debugged module that you can incorporate into your system to handle the great bulk of the low level detail work. But I would fault rdiff or tar, or some other well known software as a starting point. HTH -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup correction
s/would fault/would not fault/ On 20091030_192015, Paul E Condon wrote: On 20091030_010001, lrhorer wrote: Alex Samad wrote: On Fri, Oct 30, 2009 at 01:37:51AM +, Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Or have a look at rdiff-backup This doesn't sound to me as if it fits the bill, either. It sounds closer than rsync, but I didn't read anything about changing drives or maintaining an index. Rather, it sounds to me as if it merely creates directories with diff files on them on a single remote target. This strategy won't work when one's targets are much smaller than the array being backed up. I haven't seen any 20 TB drives for sale, so this backup and restore has to span multiple target drives, all but one of which are offline at any given time. I can't remember the details of your original post, but I remember reading it. Given your responses to several suggestions, I suggest that you should reconsider rsync, but not in the way that you seem to have been doing. I use rsync as for the core functionality of a backup system that I have implemented with a few dozens lines of bash scripts. My backup system is very compact and does exactly what I want for a cluster of four hosts. I didn't offer it, because it doesn't do what you want, and, frankly, I remembered your specifications as being poorly thought out. I think there are a lot of different ideas as to what a backup system should do. It was a useful learning experience for me to write my own. My reading of your responses is that it might also be a useful learning experience for you to write your own. If you embark on such a project, I think you should not start from scratch with a C++ compiler, only. Rather you should take rsync as a functioning, debugged module that you can incorporate into your system to handle the great bulk of the low level detail work. But I would fault rdiff or tar, or some other well known software as a starting point. HTH -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Recommended Linux Backup
Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives 2. Span multiple target volumes 3. Maintain a virtual fileysystem so all snapshots look like a single backup to the user. 4. Maintain an easily monitored index so the user can see which drive will be needed for a particular backup or restore operation. 5. Be able to easily rebuild the index and virtual file system from the backup drives (preferebly just one drive) if the database is lost on the source system. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives I rsync to a removable usb drive, myself. Works great. /tony -- http://www.baldwinlinguas.com Translation Interpreting Así también, la lengua es un miembro pequeño, y se gloría de grandes cosas. He aquí, un pequeño fuego ¡Cuán grande bosque enciende! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. On Fri, Oct 30, 2009 at 1:06 AM, Tony Baldwin photodha...@gmail.com wrote: lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives I rsync to a removable usb drive, myself. Works great. /tony -- http://www.baldwinlinguas.com Translation Interpreting Así también, la lengua es un miembro pequeño, y se gloría de grandes cosas. He aquí, un pequeño fuego ¡Cuán grande bosque enciende! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Paulo A.Braz Free Lunch ?! There is no such a thing !!
Re: Recommended Linux Backup
On Fri, Oct 30, 2009 at 01:37:51AM +, Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Or have a look at rdiff-backup On Fri, Oct 30, 2009 at 1:06 AM, Tony Baldwin photodha...@gmail.com wrote: lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives I rsync to a removable usb drive, myself. Works great. /tony -- http://www.baldwinlinguas.com Translation Interpreting Así también, la lengua es un miembro pequeño, y se gloría de grandes cosas. He aquí, un pequeño fuego ¡Cuán grande bosque enciende! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Free societies are hopeful societies. And free societies will be allies against these hateful few who have no conscience, who kill at the whim of a hat. - George W. Bush 09/17/2004 Washington, DC signature.asc Description: Digital signature
Re: Recommended Linux Backup
Paulo A.B. wrote: It's based on Rsync, but has a different flavor. Try ribs http://www.rustyparts.com/ribs.php. Please see my respose above. If it is based on rsync, I would expect it to have most of the limitations of rsync, adn I don't see in the README that it would seem to do what I need. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Recommended Linux Backup
Tony Baldwin wrote: lrhorer wrote: Other than tar and rsync, I have never used any Linux backup utilities, and I am looking for recommendations. I would like an open source solution which will do the following: 1. Back up to removable hard drives I rsync to a removable usb drive, myself. Works great. Rsync can span multiple target drives? That's news to me. How can it decide what to transfer when the target drive contains almost none of the backup set? You also seem to have ignored all my other requirements, because I am almost sure it doesn't supports virtual backup file system and snapshots., nor do I know how it can be induced to create an index or to rebuild one from a backup set. If I ma mistaken, please enlioghten me with the command line switches which can be used to implement these utilities in rsync. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
