We've been using rsync for years with no issues. Our script pulls into a central server around 11pm when there is virtually no activity on 95% of our customer boxes. A snapshot technology would be arguably better, but would require LVM and all of the extra complexity. Not worth it with what we're doing here.
We take the /oldroot/mnt/asturw directory and have used only one partition on nearly all of our boxes. We also use rdiff-backup to create a duplicate of those backups which allows us to recover backwards to however far back we choose to maintain (I believe we're doing approximately 90 days). Darrick ________________________________________ From: Lonnie Abelbeck [[email protected]] Sent: Thursday, February 20, 2014 7:51 AM To: AstLinux Users Mailing List Subject: Re: [Astlinux-users] Is my CF card failing? I think Christopher is on target. Taking Christopher's thinking in another direction, the rsync (when spawned) is operating on a live changing filesystem and to complicate things the rsync is operating only on the RW layer of the unionfs filesystem... all on a slow CF drive with DMA disabled (in your case). What happens when rsync is transferring a file from /oldroot/mnt/asturw that unionfs changes indirectly ? I don't know that answer, but it is indeed complicated, though I would expect rsync would be be happier if operating directly with a changing filesystem rather than indirectly via a unionfs layer. Of course things could work perfectly 99.99... % of the time, it is the 0.00...1 % of the time at issue. Personally I always use separate partitions for /oldroot/mnt/asturw and /mnt/kd when setting-up the system using setup.php or initial-setup. In this case your rsync backup scheme would have to be called twice, once for /oldroot/mnt/asturw and once for /mnt/kd, but the good news is unionfs is not involved with /mnt/kd in this case, which contains all the live, changing files. Lonnie On Feb 20, 2014, at 6:19 AM, The Cadillac Kid wrote: > I have had failed CF cards act like this and work fine after a power cycle > for awhile... what I "THINK" happens is that the wear levelling in the car > gets to the point it responds too slowly to the kernel.. the eventual result > will be linux remounts the card read only after so many failed reads / > writes.. > > the cards i lost in the field would test perfectly fine with linux and > windows utilities... put them back into service in the soekris and same > errors would come back after a few days.... or sometimes a few hours > -Christopher > > > > On Wednesday, February 19, 2014 7:39 AM, David Kerr <[email protected]> wrote: > rsync is running on a separate server, a ReadyNAS, connects to astlinux over > ssh to pull the contents of asturw and save it on the server.... > > rsync -avz --delete -b --backup-dir=/c/home/david/PBXbackup-old -e "ssh > -p<myport>" [email protected]:/oldroot/mnt/asturw /c/home/david/PBXbackup > > David > > > > On Tue, Feb 18, 2014 at 10:21 PM, Benjamin L. Naber <[email protected]> > wrote: > Are you using rsync to copy files to the same CF that your firmware is > on? > > If so, you are going to cause the CF to fail earlier than expected, or > if it really is failing but no showing signs, you will surely cause it > to fail. > > Perform your backups to some other media such as USB flash/hard drive, > or you can get really fancy and make it backup over the network via NFS. > > ~Benjamin > > > On Tue, 2014-02-18 at 21:25 -0500, David Kerr wrote: > > So, I removed the CF card and plugged it into another linux system and > > ran fsck. No errors were found. So I backed up everything then put > > the same card back into my Alix system and rebooted. Everything is > > working fine. I have no idea what the problem was but I will keep an > > eye on the logs closely for the next few days and see what happens. I > > have backup and am running a rsync backup or asturw hourly so I can > > recover if necessary. If problems occur again I can always replace > > the Alix board as I have a second one that I used for test purposes in > > the past, but is presently unused. > > > > > > David > > > > > > On Fri, Feb 14, 2014 at 12:58 AM, Darrick Hartman > > <[email protected]> wrote: > > Back it up and get a new card. It looks like you are having > > some sort of hardware problems. > > > > -----Original Message----- > > From: David Kerr [[email protected]] > > Received: Thursday, 13 Feb 2014, 11:42PM > > To: AstLinux Users Mailing List > > [[email protected]] > > Subject: [Astlinux-users] Is my CF card failing? > > > > My log is full of the following messages. Many day's worth. > > Looks like I have a CF card problem? Appears that CDRs are > > not being logged either. I'm afraid to reboot the device in > > case it doesn't come back up again. > > > > > > Thoughts? > > David > > > > > > > > > > > > > > > > > > Feb 13 23:54:32 pbx user.err kernel: end_request: I/O error, dev > > sda, sector 3145704 > > Feb 13 23:54:32 pbx user.err kernel: EXT2-fs (sda2): previous I/O > > error to superblock detected > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] Unhandled > > error code > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] Result: > > hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] CDB: > > Write(10): 2a 00 00 03 ff c0 00 00 08 00 > > Feb 13 23:54:32 pbx user.err kernel: end_request: I/O error, dev > > sda, sector 262080 > > Feb 13 23:54:32 pbx user.err kernel: Buffer I/O error on device > > sda2, logical block 0 > > Feb 13 23:54:32 pbx user.warn kernel: lost page write due to I/O > > error on sda2 > > Feb 13 23:54:32 pbx user.crit kernel: EXT2-fs (sda2): error: > > ext2_get_inode: unable to read inode block - inode=171522, block=360453 > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] Unhandled > > error code > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] Result: > > hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] CDB: > > Read(10): 28 00 00 08 05 30 00 00 08 00 > > Feb 13 23:54:32 pbx user.err kernel: end_request: I/O error, dev > > sda, sector 525616 > > Feb 13 23:54:32 pbx user.err kernel: EXT2-fs (sda2): previous I/O > > error to superblock detected > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] Unhandled > > error code > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] Result: > > hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK > > Feb 13 23:54:32 pbx user.info kernel: sd 0:0:0:0: [sda] CDB: > > Write(10): 2a 00 00 03 ff c0 00 00 08 00 > > Feb 13 23:54:32 pbx user.err kernel: end_request: I/O error, dev > > sda, sector 262080 > > > > > > ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Astlinux-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to [email protected].
