Slashdot Mirror

As a bonus, you can use it to transport data (eg. your mp3 collection) between places, or even use it to boot linux anywhere with much more space and document storage capability than Knoppix.

Mike Rubel, for developing a simple method to take NetApp style snapshot backups on any Linux server.

http://www.mikerubel.org/computers/rsync_snapshots /index.html

Maybe try BackupPC, which I believe supports rsync and SSH on Windows (with cygwin).

Here's another good site on backing up Windows machines.

another way to use rsync for incremental backups

I mentioned this on another thread but the way to do this is to use incremental backup w/ drives. Take a look at this rsync script We do this over the network via ssh to drives. This gives us remote backup, snapshots and cost effectiveness of drives. In addition the "snapshot" directories are useraccessible so it is very easy for anyone to personally unroll.

-bloo

A very cost effective cheap disk method uses backup to disk method that we use is backup to raid 1 disks over the network. In fact we are using rsync w/ incremental hardwired backup. We get daily, weekly, and monthly snapshots w/ drive space onl being sets of changes. What is actually really nice about this, is you end up w/ a set of accessible directories which look like they contain the snapshot which makes it very easy for people to "unroll" w/out any admin intervention. We are rsyncing over ssh so it is reasonably secure. This is just "code" so our take is as long our local machines and the remote backup dont simultaneously die we should be okay.

-bloo

I had a similar problem once. Up until about 2am finishing a TCP/IP simulator program in C for my networking class. Had the project basically finished, was just cleaning up, and did "rm -rf core *" instead of "rm -rf core*" (note the space!). I was using a box with ext3 instead of ext2 - doh! Can't just unmount the filesystem and go find your file with ext3. I had to vi the entire filesystem (~12GB) and patch together pieces of the file. The program never did work right again and I ended up with a B on the assignment (only B ever in that class :(). Needless to say, I learned my lesson and now use Snapshots.

In a somewhat unrelated (and more painful) story, using my vast intellect I once attempted to replace a PCI card (of some sort) in a running computer and shocked the shit out of myself. Twice . In less than ten minutes. Apparently I didn't learn that lesson.

- Ben

Using RSync to do snapshots is a good way to go. With the snapshot structure on the RAID system, you cannot accidentally wipe out data: it'll remain in the past versions.

I work for a small company that only has three full-time employees (including me). I use two Debian boxes (cheap-o machines that are just retired desktops with some big cheap IDE hard drives in them) running Samba. I use the rsync mirroring technique I found here.

One box is the "live" server and the other mirrors the live server every night. If the main server dies (which happened once - power supply failure), I can "promote" the backup server by changing one line in its Samba configuration. As a bonus, the backup server keeps "snapshots" back a week or two.

In fact you can use rsync w/ hard links to automate all of this. Its actually a hell of a lot more convenient than tape backups as you can mount the raid drive as RO and let everyone see their own daily/weekly/monthly/6 monthly snap shots w/out needing any admin intervention. CVS for the lazy :). We do rsync/raid backup trick on all our machines w/ the raid machine in a different room. It won't save us if the building burns down but is reasonably useful for some semblence of backup sanity

-bloo

2. tar will not pick up HFS forks. Resource forks are somewhat more rare in Mac OS X, but they're still there and some programs won't work without them. Finder forks are everywhere in Mac OS X, and while they're not critical, Mac users refused to use a backup system I provided when it did not preserve finder forks.

You can convert HFS resource forks into regular directories/files that will be picked up with tar/rsync/cpio/whatever. Resource forks can be accessed with the syntax "file/rsrc" or "file/..namedFork/rsrc". You can then copy the resource fork into a file called "._file" parallel to "file" and it will be preserved. This is how resource forks are handled on UFS, but it works on UFS and HFS.

So you can do "mv file/..namedFork/rsrc ._file" to prepare file for backup by tar. Put it in a script with a "find" command and you can convert an entire filesystem. (Obviously, do your experimentation somewhere where you don't care if you break your file system.)

Aliases are files with zero-length data forks and the alias information in the resource fork. If you preserve resource forks in one of the above manners, you preserve aliases. Otherwise, you just get regular empty files. I don't know how relevant this is for a backup/archival system as aliases usually break when you move them between systems due to differing volume IDs.

Unfortunately, it's not possible to access the finder fork (creator, type) from the command line using standard utilities. If you want something that also preserves finder forks, it's possible to create, mount and manipulate HFS disk images (.dmg) from the command line using utilities supplied with Mac OS X. The commands you use are hdid, hdiutil and ditto. This is a PITA, but I just found someone who automated it: http://www.kernelthread.com/mac/apme/archive/

Unfortunately, you can't access dmgs using standard utilities on other platforms, so this method is of limited usefulness. One of the main points of using tar (for me at least) is cross-platform compatibility: I need to access these files on non-Mac OS X systems (like a Solaris box or my NetBSD/SPARC machine, platforms that commercial vendors are unlikely to port to) but I would also prefer to have the metadata preserved when moving between Mac OS X systems. Other reasons to use tar are that (1) tar archives will remain accessible virtually forever due to their ubiquity (whereas an esoteric backup program probably won't have a version for OSes ten years in the future) and (2) tar comes standard with MacOS X, so your backup system will always work (whereas you may have to wait for your backup vendor to release a new version of their program for 10.4, 10.5, etc., assuming the company exists at that time, but if 10.4 introduces some incompatibility in a script I wrote, I can fix that myself in minutes), and the final reason for using standard command-line utilities is (3) flexibility: you can do anything from any kind of incremental schedule to simulating filesystem snapshots, selectively choosing which files to back up, how often and where and automating the entire process so it's completely transparent to your users.

Back in the days of 10.0, I had a long list of problems with Mac OS X that kept me from using it as a serious Unix system. Some of these were relatively minor and esoteric problems that I doubt many others encountered. Amazingly, each one of these except one has been fixed by 10.3. The only remaining issue I have with Mac OS X is that I can't access finder forks using POSIX APIs. If someone could rectify this, that would be really nice :)

FWIW, I personally like the SPF approach.

I don't know how any meta-information on files is handled with BeOS. Under OS X, connecting through Samba stores the meta-information in a hidden file in each directory.

Use disks. See : Mike Rubel's rsync backup system. You can't beat IDE disks on price/gb - Tapes are MORE expensive; They're fast, available on-line, and you'll probably be able to mount them on any machine in the next 10 years (which is not true for many tape drives).

FYI, here are the (4) proposals that I know about:

RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).

DMP - No change or update since this was posted back in August 2003.

DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.

SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.

Anyone have any inside track on where these proposals stand?

Would you rather choose a Yahoo product over an open standard that is under development? I'm speaking of AMTP, of course. (See AMTP author's site).

Yahoo's size doesn't give that much weight to their proposal. Yahoo's email is not used in business to business communication (do not count hot dog stands as businesses), so businesses can just aswell block everything that originates from *@yahoo.com if it is not directed to their consumer service department.

Also, reverse mx records provide much of the same benefits with minimal alterations needed to current email infrastructure. One DNS record added and small change in MTA software.

If Yahoo would really like to do a service to the internet community, they should rather consider looking AMTP and reverse mx records.

Absolutely not. You know that there are indeed programs that do not use libc, even in Linux? Unix programmers (usually) do not resort to these sort of shenanigans. You are correct in that the KDE/GNOME vfs folks are going in the wrong direction. The things they are doing should be done in a system-wide way, but mp3-ripping code does not belong in the kernel, rather in userspace. Linux has some experimental userspace filesystem stuff, but not BSD/Solaris/etc. which KDE/GNOME also support. The correct solution would be to have this built into the system from the start, like plan9 does it.

NT does it completely wrong in that the documentation for this stuff ("installable filesystems") is only available coughing up $1000 (and very likely signing an NDA). Projects like ext2 for NT are based on a lot of reverse-engineering.

I believe otherwise hard links are useless and can be replaced with soft links, any persistant hard links are just confusing.

I give a short quiz to every person I interview for a position. One is "demonstrate a reasonable use for a hard link." Possible examples:

1. A certain program runs in a chroot environment. The only way to give this program open() access to files outside its the chroot environment is through hard links.

2. You are making a rescue disk or a flash-based router which uses busybox and is extremely limited on disk space and inodes. Hard links do not use inodes but only directory entries.

3. You have a third-party proprietary program that checks if a file is a symlink and you want it to use a symlink.

4. You have a third-party proprietary program and you wish to bypass its locking semantics. For example, VMWare for Linux will lock a virtual disk file and the utility for mounting this virtual disk host-side also attempts to lock the file. I needed to bypass this locking (I knew what I was doing, it's my data) and was able to do it in a couple seconds with a hard link, whereas I would have to hack libc or the kernel to do it without hard links.

I name these four things as these are the things I've done with hard links at some point or another. Some interviewees came up with original and creative responses.

For an example of a number of these ideas used together, read about snapshots with rsync.

You mention atomic renames, but Unix provides atomic rename(2) functionality (NB: (2), not (3)). I'm not sure how renaming with hard links would really very useful because if the system crashes between link() and unlink(), you end up with two links, so this isn't really atomic.

Mac OS/9 "semi-soft links" sound very interesting, but they do need significant changes to Unix file systems.

MacOS "aliases" are basically hard links that work across devices. The alias contains a file number (akin to an inode number) and a volume number. If the original file is moved from one volume to another, the alias fails. No path information is recorded in the alias file, so there is no fall back to symlink behaviour when the original file is moved to a different volume. All the information is recorded in the resource fork and the alias file has an "isalias" bit in the Finder fork.

In MacOS 9, aliases are handled by the Finder and the standard file-open dialog, although there are alias APIs for applications. MacOS 9 was very strange in that programs very rarely opened files themselves, but rather opened files only via user interaction (double-click in Finder, open dialog or drag-and-drop). If you tried to access a file's resources directly without first checking if the file is an alias (and resolving the alias), you might get garbage (accessing the file's data gives you an empty file); obviously, th

You might want to take a look at Easy Automated Snapshot-Style Backups with Linux and Rsync posted by Mike Rubel. I think this is mentioned in the book Linux Server Hacks by O'Reilly (hack #42), although I don't have the book so I'm not sure.

Basically it uses rsync and cp to create a backup, but only changed files are actually copied; unchanged files are simply linked to. This saves a lot of disk space, and allows you to keep many backups on the system at one time, assuming most of your files don't change.

Here is a nice page that explains how to do incremental backups via rsync and ssh. It shows how to do nice incremental backups using only slightly more space than the source (for the differing file versions). This makes for a pretty cheap and easy backup solution. Plus with this sort of setup you could place the backup server (or even better serverS) anywhere they can be connected to the internet.

Most residential broadband connections have pretty limited upstream bandwidth, but unless you are restoring from backup often, the availible downstream bandwith would probably be sufficient to back up several GB of data over-night to a backup server at home*.

* I am assuming you are the owner of a small business and would want to back up said business' data at home.

This is certainly good news. Now their customers who are infected will figure things out pretty quickly!

Of course, this would have been easier if they just blocked egress port 25 traffic (which would not include their own SMTP server, of course!). Imagine all ISPs blocking egress port 25 traffic for their DHCP clients (e.g. most cable modem, dial-up, and DSL), and shutting off their corporate clients who spew spam! That would effectively eliminate spam, since IP addresses left still sending spam (directly or due to a trojan/virus) would quickly end up on DNSBLs.

It is irresponsible for ISPs to operate otherwise. Simple steps to be a good netizen:

• Don't use port 25 for initial mail submission. The fact that this port is used for both mail transport (between systems) and initial mail submission (which is really a different activity if you think about it) is a mistake. Use port 587 with SMTP+AUTH, or port 465 with SMTP+AUTH+SSL
• Implement one of the reverse lookups for incoming SMTP traffic (RMX or SPF:Sender) when one of the competing proposals become a standard (and your software catches up)
• Block egress port 25 traffic from your network

How to do this is spelled out in the book Linux Server Hacks by Rob Flickenger. See tips #41 and #42.

Or see online:

http://www.mikerubel.org/computers/rsync_snapshots /

The beauty part: export the snapshots back to the users with NFS. When they lose a file they can get it back without asking the sysadmin to do it!

steveha

Here is a nice page that explains how do do this. Even better, it shows how to do nice incremental backups using only slightly more space than the source (for the differing file versions). This makes for a pretty cheap and easy backup solution.

The biggest problem is ATT will have to administrate this. If a (legitimate) domain switches IP addresses on their outgoing SMTP server (it happens), ATT will have to deal with it by setting up some kind of structure to accomodate such changes.

Forcing domains to declare from what SMTP host legitimate mail will come from is actualy a good idea. It has been proposed before, in the form of SPF:Sender and RMX. Either would do the job (technical quibbles aside), and would accomodate the end goal ATT is trying to achieve.

LVM can do snapshotting. Check the "lvcreate -s" option. If you're looking for something more backup-like, you might want to take a look at Mike Rubel's rsync-snapshots page. I'm currently using a package called dirvish to do rsync snapshots to my backup server. Works like a charm. :)

I once accidently deleted a file under my shiny new ext3 file system. Now, under and ext2 fs it is a piece of cake to recover a lost file - unmount the partition (ok, a little tougher if it's the root fs, but nonetheless) and go at it. Not so easy under ext3, however. I had to get a hard drive examination tool, dd the entire partition into a single image, and vi the (~13GB) file, /ing for the bits and pieces of my file.

Now I use snapshot style backup scheme. Works great.

Isn't this exactly the same as RMX (reverse MX), but with a much less cool name?

"Sender Permitted From" makes no sense without context, while "Reverse MX" tells you exactly what it is. RMX is a much cooler sounding acronim then SFP, IMO.

The central idea behind reverse-DNS/MX proposals is to answer the following 2 questions:

1. Does a particular domain have a list of authorized IP addresses that are allowed to send out e-mail on behalf of the domain?

2. Is the IP address of the mail server that is attempting to talk to me on that authorized list?

The devil is, of course, in the details/implementation. (Can we do it without breaking older versions of BIND? What attacks is it suspectible to?)

Here's the (4) proposals that I know about (since I just went looking yesterday):

RMX proposal - No news on Mike Rubel's page since June 2003. Not much on the official home page either. The last published draft is June 2003.

DMP - Last IETF draft published Aug 2003 and expires at the end of Sep 2003. However, version 5 of the document has not yet been posted and the author(s) does not have seem to have a central site to check for news.

DRIP - Last draft was published July 2003, expires Dec 2003. I don't see anywhere a central home page to check for news.

SMTP+SPF - Last update was mid-July 2003. I'm not sure if there is an IETF draft being floated or not.

Here's the current list of the 4 proposals that I know about.

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

All (4) of those perform pretty much identically, with various trade-offs. The 2 key questions that an SMTP server needs answered are:

- does this domain have reverse-MX information?

- is the origin IP address authorized to send e-mail for the purported origin domain?

And possibly a 3rd question for farther down the road (although this is possibly over-kill):

- has the e-mail been properly signed by the sender of the e-mail

IIRC, NSLookups fail because it makes the assumption that everyone is in control of their reverse IP info and that people don't service multiple domains from a single IP address.

Or one of the other proposals (personaly, as a mail admin, I don't care which of the proposals make it so long as I can stop having my domain name forged onto e-mails that we didn't send):

RMX proposal

DMP proposal

DRIP proposal

Unfortunately, it'll probably be 2-3 years until the standard organizations get off their duffs and pass something.

There are currently (at least) 4 different proposals that I know about to end the process of domain spoofing (which is part of the battle).

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

C/R also suffers when it comes to mail lists... the response is usually that we can just whitelist the mailing list domains.

Except that spammers can forge their domain to match that of a domain that is on the whitelist.

SPAM is a multi-facted issue... one of the first facets that I hope gets taken care of before we all grow old is that the IETF approves one of the RMX / SMTP+SPF style proposals and eliminates "joe jobs" and forged domains.

>> ISPs' incoming servers accept mail only if the "sender:" matches the domain of the server that is sending the message

Which is exactly what proposals like RMX / SPF and others are attempting to do. Since the DNS system is already used to designate which IPs will accept inbound e-mail for a particular domain - why can't DNS be queried to find out if a given IP is authorized to send e-mail for a particular domain.

Explanation of RMX
SMTP+SPF proposal

As a side-effect of the RMX/SPF style systems that a given e-mail comes from an authenticated IP for the purported domain is that e-mail worms will find it more difficult to spread directly from infected systems straight to target SMTP hosts. Instead, those worms will have to spread by passing through the user's official SMTP server.

Well, as you have seen from the previous posts, the term snapshots is interpretted differently by different people.

If you mean an image of the disk, when you say snapshot, then you will have to use something like partimage or ghost4unix. These will require that the NT4 server be shut down while the image is taken. The Norton Ghost for Servers can do live images.

If you mean you want a point in time copy of the server's files, when you say snapshot, then Rsync is your friend, with Samba client. Look at this how-to for a quick and easy Rsync based rolling snapshot backup. The only problem with this method is that you will lose the NTFS permission attributes on the backed up files.

Actually, RMX does reduce the utility to spammers of compromised home machines. There is a nice discussion of this property here.

Great write-up on RMX, brought to you by the same guy who came up with an easy way to snapshot.

Great write-up on RMX, brought to you by the same guy who came up with an easy way to snapshot.

The permission thing. Having to map the user and group names is inconvenient. For one, you have to maintain those users and groups.

Well, as I said you can use numeric id's if that's more convenient. Doing that they may (or may not) make sense no the target system, but there's really no other way to do it besided using a specific backup solution (that maintains its own internal mapping/whatever). A bit much to ask from a file syncronisation program IMHO.

Change sets. There is no sense of history: I can't go back to a certain date and get a snapshot of the data as it was then. This is absolutely required in certain scenarios. Of course, you could rotate among several different target directories, just like you would rotate tapes, but that wastes disk space that you might not possess.

That's supported by rsync, and quite nicely I might add. You can do differential backups, with your last backup being the full backup, and earlier ones being saved. Granted it won't do diffs of the contents of files, but rdiff-backup doesn't do that either, does it?

The root issue. It would be much nicer if there was a server component running as root, which permitted specific users to connect and backup files.

Oh, but there is. You can run an rsync daemon as root on your backup machine. It ever supports authentication. But you lose the 'ssh' capabilities so you'd better run it on an internal trusted network.

Incidentally, rsync seems to not care about file name character encoding, which is a big minus. The port of rsync to Mac OS X will not transfer files containing 8-bit characters (eg., accented characters, Scandinavian letters), barfing with an "operation not permitted"-style I/O error. It seems that the Mac OS X APIs want UTF-8 file names. A simple internal translation should work.

Never came accross that one as I only sync between linux and linux (and I'm Swedish so the odd LATIN-1 char has slipped in from time to time). IMHO, converting filenames as text to and from different binary formats having to consider differing locales and whatnot is fraught with peril, and a gargantuan task. I'm happy with the current "just copy the binary" strategy. And UTF-8 should die BTW... ;-)

I know this isn't quite what you asked for, but check out http://www.mikerubel.org/computers/rsync_snapshots / for advice on using rsync to create "snapshot" like backups.

Brilliant solution that could REALLY cut down on illegal spam: http://www.mikerubel.org/computers/rmx_records/

Mike Rubel has an excellent page on snapshot backups using rsync.

This document describes a method for generating automatic rotating "snapshot"-style backups on a Unix-based system, with specific examples drawn from the author's GNU/Linux experience. Snapshot backups are a feature of some high-end industrial file servers; they create the illusion of multiple full (up to ownership/permission) backups per day without the space or processing overhead. All of the snapshots are read-only, and are accessible directly by users as special system directories. It is often possible to store several hours, days, and even weeks' worth of snapshots with slightly more than 2x storage. This method, while not as space-efficient as some of the proprietary technologies (which, using special copy-on-write filesystems, can operate on slightly more than 1x storage), makes use of only standard file utilities and the common rsync program, which is installed by default on most Linux distributions. Properly configured, the method can also protect against hard disk failure, root compromises, or even back up a network of heterogeneous desktops automatically.

Here's a howto for rsync snapshot backups. I keep daily backups for two weeks, weekly backups for two months, and monthly backups forever. I rolled my own wrappers for this stuff in a few hours.

It is about eight zillion times better than tapes. I have hot, random access to all versions of all my files. Thanks to the hard linking, space used is moderate. Since it backs up to a remote computer, backups are instantly off site. And if I want to verify my backups, I don't have to feed in eight million tapes; I just write a little perl script.

I recommend it highly!

Someone has packaged this nicely, and it was posted on slashdot sometime ago...

Rsync Snapshots

We're doing this in an enterprise environment, but it would be easy to co-ordinate between two friends as well.

--derek

gambitdesign.com

I just wish the customers would exercise a little intelligence and backup their data before their drive goes south.

Consumers buy a new computer. They expect it to 'work'. They don't want to have to be back every two months with another problem, and they certainly don't expect to lose the resumees they've typed and recipes they've collected. I mean, who would?

So we're quoting out a new system. We throw in a CD-RW and a handful of CD-RW discs. They ask why. What do we tell them? "You should back up your data so that you're prepared for your hard drive failing miserably."?!? Sure, we could make up an excuse about power surges, water damage, etc. but they still pry, and they tend to determine that we're trying to sell them a lemon and then put them to work for it.

We had one customer, a business owner, who experienced a bad hard drive (Western Digital 80GB ATA100 7200RPM). So I sold him a few CD-RWs to use in his 32x12x40 CD-RW drive to back up his important data. Some four months later he was in for a copy of his invoice for his insurance company because his computer was stolen. "Did they steal the CD-RWs?" I asked. Timidly, he informed me that he hadn't gotten around to backing up.

See, even after catastrophic failure people can't be convinced that they have to back up their important files daily or weekly.

Ideally, we'd sell atleast one computer to all of our business clients with a 20/40GB Travan drive in it, they'd allow us to configure a nightly backup routine, and we convince the receptionist to swap labelled tapes every night on her way out the door. But hey, that would make sense. Of course, customers see a potential $2k bill for such a setup and they balk.

I'd love tell them "I told you so!", but that would lose us a client, rather than teach them a lesson. They'd just wind up spending money at another store and not backing up their data.

At home I have a backup regimen that includes a 4AM cronjob, weekly, that archives all my variable data (home directories, mail spools, etc directories, my hosted websites, etc.), and I back all of these files up on to two CD-RW discs; one labelled "Current Week" and one labelled "Previous Week". When I get a chance, I'll be utilizing the Rsync incremental backup solution and archiving the current weekly snapshot, and saving the previous week's burned snapshot, like I'm doing now but better. {smile}

With a quick'n'dirty script and some discipline (store your files only in designated places, not all over your drive) and a weekly half-hour routine, anybody can keep their file loss to a minimum.

We're starting to offer in-home tutoring to customers, perhaps this will be a special promotion. "How to mitigate data loss 101".

Here's one method for he backups: Somebody has taken the time to put together a nice page on how to do snapshots with rsync.

An even MUCH better method (which is just some few lines shell script more) is described at here or use mirror here.

Yes, that really works - and it is so SIMPLE and USEFUL!

Thomas Waldmann

But your idea is interesting if I make regular images of my *own* W2K installation though - maybe I should give it a try...

That was indeed what I meant, images of the original install was the right thing in our case, it is clealry not in yours.
With a little scripting&boot manager magic + perhaps wake-on-lan one can even do scheduled nightly images.
Add to that netcat+dd for windows (look on google for it, there's a standalone version), and it might really be possible to that on a live system (this is dangerous though, I assume) over the net.

But what might be nice could be nightly differential backups, but since we have no use for that, I didn't try this.
It might come in handy for you, though. See for instance Easy Automated Snapshot-Style Backups with Linux and Rsync.
Sound neat.

Using rsync, I synchronize the main fileserver over to the backup computer on a regular basis. You can 'snapshot' days and weeks of data without using lots of hard-drive space by using the fine tutorial written by Mike Rubel.

I set-up the workstation's "My Documents" default to point to a shared drive (S:) on our fileserver. This automatically points everyone to the right place without even looking at their system. I also harp on how important it is to save files to the shared drive.

For laptop users, I setup a cygwin-minimal-rsync system. All backups are encrypted through ssh. Furthermore, the backup server is restricted to only running rsync backups.

Everytime they start their laptops, a batch file in the startup group opens. They can choose to abort (if they are not connected to the lan) or continue with a backup.

Because it uses rsync, only their changes are saved to the backup computer. This usually only takes a minute or two. Most users have other things to do while it is backing up.

The system cost $600. I have had two complete laptop failures since then with full recovery. Not only that, I can recover files accidently written over almost two months later. The investment was worth every single penny!